At 09:25 AM 24/12/2004 -0500, Jonathan Pryor wrote: >This is correct, but a bare `throw;' is not without penalty. Sure, you >don't lose any of the stack trace information, but you instead lose the >help of the Visual Studio Debugger, which will normally break on the >original `throw' statement, as long as that throw statement doesn't have >a matching `catch'.
Now that I think of it, re-throwing the exception likely also takes longer than a 'finally' block. The Visual Studio Debugger can, of course, be configured to break on any exception, even one matched by a visible 'catch' handler. This can work fairly well when debugging robust applications early in their development cycle (they want to catch all exceptions, but you want to know about them to find bugs :-), but then some parts of the .NET framework force an "exceptions-as-the-norm" idiom, e.g. sockets, which lack an exception-free error reporting mechanism. Debugging code that uses these areas can become tedious, where many of the exceptions that the debugger breaks on are "normal", like the "SocketException" that occurs when the other end closes the connection. =/ Jonathan Gilbert _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
