[wallyhs]

> Corruption is outside the state of this discussion.

Why? If corruption leads to an exception, it seems relevant. Corruption could be the application's own fault, it could be failing hardware, it could be someone trying to exploit a vulnerability. It could be anything - a result of undefined behavior. Sorry if I'm using the term loosely.

> If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference.

If it overwrote the other half, it should crash immediately. I can't just display an error message and retry the operation in that case. If I don't know what exception I'm handling, how can I be sure that I won't cause more damage by handling it?

> The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly.

That is not what I was referring to. A program can still get into an inconsistent state with exceptions. For example, if a function updates half of some data structure and then throws, that data structure may be left in an inconsistent state. Of course you should not write functions that way, but it is an easy mistake to make. Do you really want your app to keep running in an inconsistent state?

I'm looking at it from a defensive, assume-the-worse perspective. If my application is in an inconsistent state, it should cease running immediately. If my application does not know which state it is in, it must assume that it is in an inconsistent state.

[wvenable]

This has nothing to do with exceptions. If some function updates half of some structure and then just returns due to a bug then you have an inconsistent state and no exceptions were involved at all. And your application keeps running in an inconsistent state.

[wallyhs]

You can only recover from such errors locally. The local context is not available in a global exception handler.

[wvenable]

If your code corrupted your data structure or a cosmic ray changed a bit, you're not recovering no matter what.

[wallyhs]

That's my point: in this situation, you can't display an error and keep going. How do you know that you are not in this situation when you catch an unknown exception?

[wvenable]

But in the same situation the code might not trigger an exception and continue just the same. You've gained or lost nothing.

You have to assume that code cleans itself up as the stack unwinds. That should be normal operation whether or not you are using exceptions or not. If the exception is in the middle of modifying a data structure then the cleanup should ensure that data structure is either back into a stable state or destroyed completely.

[wallyhs]

> You have to assume that code cleans itself up as the stack unwinds.

Exceptions or not, if you have an unknown error condition, how can you assume anything?

I apologize for the delayed response.