I am actually more interested in how to emulate "throw;" within an extracted error handling method.
–
SungApr 8 '09 at 14:48

You cannot do a "throw;" inside of the extracted method itself, since the method may also be called without coming from a catch block (imagine for instance calling it with "new Exception()" as argument). The only way to achieve this is probably the one suggested in my answer with the return code.
–
LuceroApr 8 '09 at 15:08

+marked as answer: seems like the easiest to trace error back to the source and easy to read. My "HandleException" method is named as "TryHandleRecoverableException", by the way.
–
SungApr 8 '09 at 15:25

This will allow you to add your own logic, then throw your own exception class. The StackTrace of the YourExceptionClass instance will be from within this code block, but the InnerException will be the exception you caught, with the StackTrace it had before.

With .NET Framework 4.5 there is now an ExceptionDispatchInfo which supports this exact scenario. It allows capturing a complete exception and rethrowing it from somewhere else without overwriting the contained stack trace.

Interesting but would be good to see some code example
–
Konstantin SpirinJan 8 '13 at 3:19

3

@KonstantinSpirin: Thought the available methods and MSDN docs were pretty obvious, but added some sample code anyways to given an overview without having to click over to MSDN.
–
ZaratJan 8 '13 at 4:41

Are you catching exceptions that you want to then filter more carefully, so you can then change your mind, decide not to handle them and so rethrow them?

If you want to be really careful about this, that's not really a good idea. It's better to never catch the exception in the first place. The reason is that a given try/catch handler should not take the decision to run nested finally blocks for exceptions that it is not expecting to see. For example, if there is a NullReferenceException, it's probably a very bad idea to continue executing any code as it will probably cause another such exception to be thrown. And finally blocks are just code, like any other code. As soon as an exception is caught for the first time, any finally blocks on the stack beneath the try/catch will be executed, by which time it's too late - another exception may be generated, and this means that the original exception is lost.

This implies (in C#) that you have to careful write out a separate catch handler for all the exception types you want to catch. It also implies that you can only filter by exception type. This is sometimes very hard advice to follow.

It should be possible to filter exceptions in other ways, but in C# it is not. However, it is possible in VB.NET, and the BCL itself takes advantage of this by having a small amount of code written in VB.NET so it can filter exceptions in a more convenient way.

"Are you catching exceptions that you want to then filter more carefully, so you can then change your mind, decide not to handle them and so rethrow them?" -> Yes.
–
SungApr 8 '09 at 14:56

"finally" code is always executed, no matter whether an exception occurred and how you handle the exception. I don't see the relation to the question...
–
LuceroApr 8 '09 at 15:05

+1 for the link.. a useful thing that VB has and C# doesn't... strange. Maybe its because the C# designers want you to catch specific exceptions and design exception hierarchies correctly so that you dont have to catch and rethrow few specific derivations
–
GishuApr 8 '09 at 15:29

+1 Earwicker, your 2cents was really great. I would love to use "Exceptions" class somewhere in the code as well.
–
SungApr 8 '09 at 15:32

@Lucero - not necessarily. Try handling AppDomain.UnhandledException and you will find that it fires before finally blocks run, giving you the option to call Environment.FailFast before they do. But any intervening catch/rethrow will interfere with this capability.
–
Daniel EarwickerApr 8 '09 at 15:48