ThreadAbortException is a rather special case. Unlike other types of exception catching it does not prevent it from propagating up the call stack. The only way that I know to handle a ThreadAbortException is to call Thread.ResetAbort() from within the catch handler.
>From MSDN: "ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block. When this exception is raised, the runtime executes all the finally blocks before killing the thread." http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemthreadingt hreadabortexceptionclasstopic.asp and http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemthreadingt hreadclassresetaborttopic.asp 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? As far as only catching the exceptions that a method will actually throw, that is provably impossible. The implementation of a method is not restricted in the exceptions that it can throw, or the exceptions that are thrown by the methods it calls. For better or worse this is a design feature of the CLI. It is not good enough to say that we believe that a method will only throw these exceptions so we only need to catch those exceptions as that might change in a future implementation of the method. Good practice dictates that code should only catch exceptions that is knows what to do with. Log4net knows that the calling application doesn't expect the exception and won't know what to do with it. Log4net does its best not to harm the calling application, leaking exceptions would be harmful. In fact, currently, there is a whole class of exceptions that log4net does leak; exceptions that don't derive from System.Exception. C# can only catch exceptions that are instances of System.Exception, however the CLI allows any object to be thrown. Languages like C++ can throw other objects which cannot be caught by C#. It is possible to catch the exception with a catch {} block but it is not possible to access the thrown value. This should be relatively easy to fix in log4net. Nicko > -----Original Message----- > From: Dag Christensen [mailto:[EMAIL PROTECTED] > Sent: 14 February 2005 13:18 > To: Log4NET Dev > Subject: Exception handling > > Exceptions in log4net seems to be caught by "catch {}" or "catch > (Exception) {}" blocks (at least the recent check-ins are). > Ignoring the fact that you should probably only catch > exceptions that the code might generate, I'm more worried > about forcefully killing threads in multithreaded > applications using log4net. > > Since .NET don't have a way to forcefully kill a thread > (afaik), the only option you have is Thread.Abort() combined > with a ThreadAbortException handler. I had an elusive bug in > a component I wrote that turned out being caused by an "catch > (Exception) {}" handler that sometimes consumed a > ThreadAbortException. Needless to say, this was a Bad > Thing(tm) and prevented the thread (and program) to terminate > correctly. There are better ways to stop threads of course, > but since abort is there and can/will be used, it should be > handled correctly. > > Regards, > > Dag > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 14. februar 2005 11:41 > To: [EMAIL PROTECTED] > Subject: cvs commit: logging-log4net/src/Config XmlConfigurator.cs > > nicko 2005/02/14 02:40:46 > > Modified: src/Config XmlConfigurator.cs > Log: > Added DefaultCredential authentication support to loading > config from web request > > Revision Changes Path > 1.14 +13 -0 logging-log4net/src/Config/XmlConfigurator.cs > > Index: XmlConfigurator.cs > =================================================================== > RCS file: /home/cvs/logging-log4net/src/Config/XmlConfigurator.cs,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -r1.13 -r1.14 > --- XmlConfigurator.cs 14 Feb 2005 03:12:39 -0000 1.13 > +++ XmlConfigurator.cs 14 Feb 2005 10:40:46 -0000 1.14 > @@ -527,6 +527,7 @@ > } > else > { > + // NETCF dose not support > WebClient > WebRequest configRequest = null; > > try > @@ -540,6 +541,17 @@ > > if (configRequest != null) > { > +#if !NETCF > + // authentication may be > required, set client to use default credentials > + try > + { > + > configRequest.Credentials = CredentialCache.DefaultCredentials; > + } > + catch > + { > + // ignore > security exception > + } > +#endif > try > { > WebResponse > response = configRequest.GetResponse(); > @@ -547,6 +559,7 @@ > { > try > { > + > // Open stream on config URI > > using(Stream configStream = response.GetResponseStream()) > > { > > Configure(repository, configStream); > > > > > >
