[Discussion] When NOT to use Structured Exception Handling

[Pradeep1210]

1) You should care about ever error. Programs should not cause errors, so when they happen that means something was done incorrectly, or something is not stable on the system. Ignoring errors will never get you far.

That adds a lot of code that is unnecessary for us depending on specific situation. As coders, we are not decision makers. If we are told to suppress errors, we must suppress errors. So, what happens when we “intentionally” want to suppress any error that is raised? The reason could be anything ranging from business to technical.

2) you should never be jumping anywhere in code. You are talking about goto and it just produces spaghetti code. If you have some code that needs to run in a loop, and the given operation inside the loop can possibly cause exceptions to occur, then you can put SEH inside the loop, not outside the loop. This would give you the chance in your code to quit the loop based on certain error conditions, or continue processing to the next iteration of the loop. You could also split a given piece of code out into its own routine, so that you can call the routine in a loop, and handle individual exceptions in the given routine. No need to be jumping around in code via On Error GoTo type statements. This is very bad practice.

No, I’m not talking about GOTO. I’m talking about resuming from error. An error handler mechanism should provide some way to locate and optionally jump back to the same line that produced the error, and possibly resume processing from there after I have done the necessary error handling. If the mechanism provides no way, it is not robust. If the mechanism wants me to think the same way its designers thought, it is not flexible either.
Take a situation where I have a long mathematical problem, spawning many lines of code. A divide by zero may occur at any line. All I want to do in such case is that reset the divisor to 1 and continue from same line again until I have achieved my aim. And what happens if I want the user to give me a new divisor and continue when a divide by zero error occurs??

3) The only thing I can say about this is you must not be structuring your code in a way that makes it easy to debug. I am not sure if you are just saying your exceptions are bubbling up and you can't tell where they originated from (which is what a stack trace is for).

Yes, I mean the same. But I want it to break on the same line where the error occurs, so that I can examine everything in detail at that point to understand the root of the problem – all variable values, all objects, all data etc that might be related to that situation. Situation becomes complex when the error doesn’t always occur at the same point (depending on class data).

So I don't really consider an article telling people to NOT use SEH, even quoting MS who is saying you SHOULD use SEH, to be a good thing to be in the codebank.

My sole point of quoting MS was that the statement is misleading. Which code should we call versatile, robust & flexible? One that allows whatever you want to do, the way you want to do (whether it is considered right or wrong practice by others is a different issue altogether); or the one that does not provide ANY way of doing what you want to do?