Navigation: Programming Cookbook > Exception Handling >
Resumable vs Non-resumable Exceptions
An important feature of the Smalltalk exception-handling model is that it supports resumption, i.e. the exception handling code can specify that execution is to continue from the point at which the exceptional condition was detected. This is in contrast to the Java and C++ exception handling models in which execution can only be continued in the immediately enclosing scope of the handler.
The ability to resume after an exception is a very powerful concept: For example it can be used to implement a deferred resource allocation scheme. Resumable exceptions reduce the need explicitly check for recoverable failures, since the recovery can be performed in the handler, before continuing execution from the point it left off. Such a powerful capability must be applied with care if it is not to result in spectacular failure. The danger inherent in resumption is one of the reasons put forward for the non-resumable model used in C++, but another reason is that it is difficult to implement efficiently in a non-reflective programming system.
A further advantage of the resumable exception system in Smalltalk is improved debuggability. This is because when an exception handler is executed the stack has not yet been unwound, and consequently the full exception context is still visible and open to manipulation. In Dolphin one can even modify the behaviour or state which caused an exception and then restart execution under the control of the debugger to allow the computation to complete.
Although the Smalltalk exception model supports resumption, not all Exceptions are resumable in practice. Resumability is an attribute of the particular class of Exception controlled by the #isResumable test method.