In other words, why doesn C++ provide a primitive for returning to the point from which an exception was thrown and continuing execution from there?
Basically, someone resuming from an exception handler can never be sure that the code after the point of throw was written to deal with the execution just continuing as if nothing had happened. An exception handler cannot know how much context to “get right” before resuming. To get such code right, the writer of the throw and the writer of the catch need intimate knowledge of each others code and context. This creates a complicated mutual dependency that wherever it has been allowed has led to serious maintenance problems. I seriously considered the possibility of allowing resumption when I designed the C++ exception handling mechanism and this issue was discussed in quite some detail during standardization. See the exception handling chapter of The Design and Evolution of C++. If you want to check to see if you can fix a problem before throwing an exception, call a function that checks and then throws only if the problem cannot be dealt with locally. A new_handler is an example of thi
Related Questions
- In other words, why doesn C++ provide a primitive for returning to the point from which an exception was thrown and continuing execution from there?
- A Runtime exception is thrown during the execution of a listener. How does the client handle it?
- How can I get an exception thrown in the lexer to escape out to the parsers invoker?
