[Discussion] When NOT to use Structured Exception Handling

[Pradeep1210]

Structured Exception Handling (SEH) is a good and efficient way to handle errors. But there are many shortcomings with the SEH which the unstructured counterpart addresses very well. Everyone keeps on recommending using SEH over unstructured exception handling (UEH). Yet they fail to address ways to counter situations which the UEH addresses very well. I feel that it is just a futile attempt by Java type thinkers to superimpose their thinking on us VB programmers.

MSDN says:

Structured exception handling is significantly more versatile, robust, and flexible than unstructured. If possible, use structured exception handling.

But in my real life situations I find just the opposite. Apart from very specific exceptional situations, I don’t see how SEH does better than UEH. I couldn’t find one instance where you would get into a situation which is handled in a better way using SEH as compared to UEH.

Here are some specific situations which I find UEH addresses much better than the SEH. (I will put the summary in this first post, and any code examples etc. in the later ones):

1. When you do not care much about the error. Your primary concern is that your program should not stop. When it is one line of code, it doesn’t matter much. But imagine the complexity when it is 10 - 15 lines or more.
   Typical situations include memory cleanup routines, demo applications etc.
2. When you want to jump back to the same line or the next line that caused the error, usually after you have corrected the problem with the error in the error handler routine.
   Typical situations include complex mathematical or logical problems, implement a Retry/Ignore/Cancel mechanism etc.
3. Debugging complex code. Situations where you have long running code (maybe in a loop), but it errors out unexpectedly somewhere. You are having trouble spotting the line or specific case that is causing the error. You want to step into it from where it errored out, or simply break on the same line where the error occurred.
   A feature to temporarily disable all error handlers should have been handy. I liked the “Break on All Errors” feature in VB6. But it seems like they have removed it from .NET onwards. So what I do now is to temporarily put a “Resume” statement in the error handler code and put a breakpoint there; or maybe simply comment out the “On Error GoTo xxx” line. Sadly I can’t seem to do anything with the SEH in this situation, and it’s a pain in the *** debugging such code, especially when your procedure contains a lot of try…catch blocks.

More suggestions are welcome. I'll include them in this list if they fit here