Under some conditions an exception may be raised as a result of handling another exception. Below are some of the scenarios:
unwind(abort)
, also raised by abort/0.If the most urgent exceptions needs to be preserved, the following exception ordering is respected, preserving the topmost matching error.
unwind(halt(_))
(halt/1)unwind(thread_exit(_))
(thread_exit/1)unwind(abort)
(abort/0)time_limit_exceeded
(call_with_time_limit/2)error(resource_error(Resource)
, Context)
error(Formal, Context)
Note The above resolution is not described in the ISO
standard. This is not needed either because ISO does not specify
setup_call_cleanup/3
and does not deal with environment management issues such as (debugger)
callbacks. Neither does it define abort/0
or timeout handling. Notably abort/0
and timeout are non-logical control structures. They are implemented on
top of exceptions as they need to unwind the stack, destroy choice
points and call cleanup handlers in the same way. However, the pending
exception should not be replaced by another one before the intended
handler is reached. The abort exception cannot be caught, something
which is achieved by wrapping the cleanup handler of catch/3
into
call_cleanup(Handler, abort)
.