> -----Original Message----- > From: Dag Christensen [mailto:[EMAIL PROTECTED] > Sent: 17 February 2005 14:06 > To: Log4NET Dev > Subject: RE: Exception handling > > 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.
Lets hope that, if it is an issue, it is now fixed. > 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? The appender base class has to protect the client app from exceptions from the appender. The retry policy is defined by the appender implementation. For example, the AdoNetAppender has a property ReconnectOnError which determines the policy regarding reconnecting to the DB server if the connection is lost. By default this is false, the appender will not try to reconnect. In general the error handling for appenders is difficult to get right, this is something that we will need to work on in future. > > 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. I meant managed languages throwing managed objects that do not derive from System.Exception. http://msdn.microsoft.com/library/en-us/vcmex/html/vcconbasicconceptsinu singmanagedexceptions.asp Look at the second example in the above document. Managed C++ is able to throw a boxed struct, this is not something that a C# caller would be able to catch! Nicko
