Sorry for the very late reply. > I'm not sure this is true for StackOverflowException. I think the CLR team > is working on hardening the finalizer to stack-overflow exceptions... at > least the ones that occur in managed code; it may always be prone to death > and destruction via unmanaged stack-overflow.
Ahh, interesting. Of course, having a finalizer method deadlock is equally as bad and probably not practically preventable. I am almost (but not entirely) in agreement with those that say "having any finalizer method run in a debug build should be an error" (but lets not start that debate here again <grin>). > Ironically .NET does offer us a way to propagate multiple exceptions -- the > InnerException property gives each exception the potential, effectively, to > represent a linked-list of exceptions (composite design pattern). > > I agree (I think) with you: it would be nice if the CLR could somehow > automatically populate the InnerException, if/when a new exception is > thrown from within a finally block, during a stack-unwind. > > I can't think of any problems that would cause... except, well, if the new > exception already has a chain of inner exceptions. :) But hey, like I > said, it's effectively a linked list. The original exception-chain can > always be tacked on to the end, somehow, right? :/ Yeah, I was wondering about using InnerException too. Unfortunately, the semantics aren't quite ideal. When you attach B as an InnerException of A, it's really only A that continues to propagate - i.e. handler filters are only tested against the outer exception etc. So you're not really propagating two exceptions at the same time, just propagating one that happens to refer to another, which now has a decreased status. Stroustrup's argument for C++ was that there is no way to decide which of the two exceptions should have the higher status (in some cases you'd want the original, in others you'd prefer the new one). The other problem, as you mentioned, is with existing InnerException chains. In the general case you've got any number of arbitrarily long exception chains from finally blocks and an arbitrarily long exception chain causing the unwind. Sure you COULD linearize all of these into one long chain, but it's not clear to me that it could preserve the "caused" relationship implied by InnerException in all cases. Instead, maybe we need a tree of Exception objects. Maybe Exception could have an UnwindingException property that points to the original exception chain that triggered the unwind. This would still effectively replace the original (and most likely source) exception type with the new one, but that may be acceptable (is compatible with the current behaviour anyway). Another option is to consider one of the two exceptions to be unhandled, and rely on the normal unhandled exception handler to deal with it. I really don't know what the best solution would be. Seems like someone should do some research on this using real-world scenarios. The one thing that is clear to me though is that the current behaviour (throwing away the original exception source) is definitely one of the more error-prone choices. Rick =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
