[Discussion] When NOT to use Structured Exception Handling

I don't think it's Microsoft, specifically, saying 'thou must use structured exception handling!'.

Structured exception handling has been a tried and true method of handling errors before Microsoft was born; it may not have looked like it, but it was.

The issue is the VB never had it - then it did. I can telly you, I was a tough convert to it, but now I have seen the benefits. But, that isn't the mantra...the new mantra is that: 'thy program shall never cause an error!'

I stick by this - If your program causes an exception handler to fire, you have done something wrong (true, there area few areas where you have little choice to use an exception handler - file handling is an example).

There is a prevalence in the programming world to allow exceptions to 'bubble up' to the caller; I believe this promotes laziness and results in pretty crappy programs with obnoxious dialog boxes. It's a viable technique in a very few circumstances. However, if you are only performing mathematical calculations there is absolutely zero reason an error should occur. Zero. None.

But I, like 100.0% of all other people who program, are lazy. If you think you aren't then I hope someone else is scrutinizing ones code. Because I know I'm lazy, and I make mistakes, I have a global exception handler (and, hopefully, a handler for every thread I create). If that handler ever fires, it means I messed up.

Additionally, and exception handler should be used at the absolute smallest level of granularity - it's actually very lazy to just wrap a whole file writing routine in an exception handler. The larger the error handler span, the potentially larger the 'types' of errors that could occur, and the more difficult it is to generate a meaningful error message - thus most programmers don't. We end up with 'object or with variable not set' error message boxes. Arrgh!

Basically, an Unstructured exception handler does the exact opposite of what's required: wrappers large chunks of code (out of necessity, since it's actually more difficult to create fine granularity unstructured error handling); pretty much ignores most errors; allows for sloppy coding because the error handler catches and often continues, hiding the poor coding (You don't use mahogany for your cabinets if you are going to put a pine laminate on top).

The other thing about bubbling up exceptions is the farther an exception gets sent up the stack, the more chance that the app will not be in a recoverable state, and will need to be restarted.

When you handle errors as they happen properly, you can easily recover the app and the user can continue to go about using it.

If you ignore errors with things like resume next, then the app is likely in an unknown state at that point, and when the user continues to work in it, there is much more chance of it breaking down, because objects are in a miscellaneous state of being alive or destroyed or whatever, because half way through a cleanup routine that had on error resume next, it bombed out.

I would say that Resume Next is entirely possible, but I have serious doubts as to whether Resume is EVER safe. At least, I don't believe the compiler can be written to determine whether Resume even makes sense in the current context.

I suppose the whole matter is preference. You can choose to have good code that shouldn't error, or you can code sloppily, and rely on error catchers to solve your problems.

IMHO, I use error catchers in the alpha/beta stages of a program, but by the time I get that program completed, I have a full blown error system that handles any errors that might occur in the program. It's just a matter of taking the time to actually coding it, and it logically helping the program and making sense.

Resume Next is a habit I haven't even looked into, hearing so much can go wrong with using Resume Next, so I missed that boat, and don't plan on joining it.

Though all these suggestions are undoubtedly good, I think we are deviating from the base topic this thread was started in the first place. We were discussing situations where UEH works better than SEH. So we assume we are in a situation where an error will necessarily occur, and we have to choose whether to use SEH or UEH.

@Shaggy: Whether a programming construct is safe or not depends entirely on the programmer coding it and the situation. (what do you think about Do..Loop without condition?) The language should provide the flexibility to the programmer to do whatever he wants to do and leave the rest unto him. If he wants to execute the same line again, the language should provide him some way to execute the same line again. Same thing with Resume Next.

Quote:

---

Originally Posted by Pradeep1210

Whether a programming construct is safe or not depends entirely on the programmer coding it and the situation. (what do you think about Do..Loop without condition?) The language should provide the flexibility to the programmer to do whatever he wants to do and leave the rest unto him. If he wants to execute the same line again, the language should provide him some way to execute the same line again. Same thing with Resume Next.

---

First up, the language does do that. On Error Resume Next is part of the VB language and you can use it if you want to. If you take pride in the code you write though, you'll choose not to. Remember, UEH is a VB thing. SEH is the only option in C++, Java, C# and I'm not sure what other languages and I don't hear any developers from those camps bemoaning the lack of a construct like On Error Resume Next.

Secondly, there seem to be a lot of people posting to this thread who have never had an issue handling any of their real-world exceptions and maintaining the flow they desire using SEH. You seem to be the only one insisting that there are situations where UEH would be better yet you have yet to provide a realistic example. If you're the one insisting that there are situations where UEH would be better yet you can't even come up with a real-world example then the only conclusion I can draw is that either such situations don't exist or that they are so uncommon as to be insignificant. I have never coded in VB6 so I didn't get used to using On Error at all. I've never used it in VB.NET and I've never met a situation where I thought it could offer me something that a Try...Catch block couldn't.