>Can't something like this VB.NET code guarantee that there is no >exception raised in a Finally block:
Kinda... but you don't want to silently swallow those exceptions, though. You might be masking a serious problem -- and you'd never know about it! The argument we're beating around is this: wouldn't it be nice if the CLR could recognize when an exception is occurring within the finally block, and behave appropriately depending on whether we're in the normal flow of execution, or in the midst of a stack-unwind? If we enter the finally block in the course of normal program flow, then exceptions should be allowed to propagate out. (No problem, this is the way it works today.) But if we're in the finally block because an exception occurred somewhere upstream, it would be nice if the CLR would not totally lose that exception -- rather, tack it on to the coattails of any new exception that gets thrown. That's the tricky part, that only the CLR can really do for us: know whether the finally block is being executed in normal program flow, or during a stack-unwind... and, in the latter case, append that original exception-chain onto the end of any newly thrown exceptions, so no information is lost. -S =================================== 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
