Hi, > I am surprised that you say that a catch(Exception) was consuming a ThreadAbortException as unless you call > Thread.ResetAbort() the exception should still propagate. Are you sure that this was the case?
I was 100% sure until now :-/ Most likely I fixed another bug when cleaning up the code (or, crossing fingers, there was a bug in framework 1.0 pre servicepacks that I used at the time). Anyway, I've been believing that was the problem for more than two years. Note the "probably" I put in my message regarding catching specific exceptions. I usually don't bother if it was exception A or B that was thrown, I just want to detect it, log and move on (and only tell the user if I have to). Appenders though, could in some cases try to prevent specific exceptions from being repeatedly thrown because of, say, an unavailable server. From what I've seen in log4net's appender code, no attempts are made to prevent exceptions from being thrown repeatedly except they will only be logged once per appender? > however the CLI allows any object to be thrown. Languages like C++ can throw other objects which cannot be caught by C#. I thought all unmanaged exceptions was wrapped by the CLR in an ExternalException-derived class? You should at least see the HRESULT, and for errors originating in COM+ objects written in VB6 I've seen the original error message. Regards, Dag Christensen Vestfold Butikkdata AS
