> The claim is not that the problem is in the code. But exceptions act very much like the problem was the code. They cancel the following code in any function

> The claim is not that the problem is in the code. But exceptions act very much like the problem was the code. They cancel the following code in any function on the stack, which in general is unrelated to the error in the state where the exception originated. Another problem is that the exception originates from code instead of the object that is in a bad state. In other words, you need to step on a landmine to even notice that the object was already bad. It would make much much more sense if the "exception" was stored with the object/handle instead of propagated up an unrelated call stack, a single time. With Erlang exceptions, the model might fit better I don't know. I looked at it many years ago but never used it.