exceptiondylan

What's the point of restart handlers?


Must a restart handler be signal-ed from within another handler, or can it be signal-ed directly by the code where the exceptional condition was detected?

If it must be signal-ed from within a handler, why is it so? it seems like a needless extra step.

What is the added value of a restart handler as opposed to a regular handler; if we dispensed with restart handlers altogether (but not with regular handlers)? Would it make any difference as to the power or expressibility of the language?


Solution

  • The following answer should be taken with a grain of salt. It is based on my understanding of the section "Conditions" in "The Dylan Reference Manual", however I have never written a single line of Dylan code and have not even read much more of the reference manual than said section.

    Must a restart handler be signal-ed from within another handler, or can it be signal-ed directly by the code where the exceptional condition was detected?

    A restart is a condition, as shown in Figure 11-6 of the reference manual. It can be signal-ed whenever a signal statement is syntactically valid. There is no special mechanism for installing handlers for restart conditions as opposed to handlers for non-restart conditions (in contrast to such languages as Common Lisp and R).

    The only difference in signaling a restart as opposed to signaling a non-restart condition is that if a restart handler is signal-ed from within another handler, the rest of the handler code that lexically follows the signal-ing will not be executed even if the restart handler returns. In this case, the execution of the handler that signal-ed the restart, as well as the execution of the handlers that invoked this handler, stops and the values returned by the restart handler become the values returned by each of these handlers. ("If the restart handler returns some values, signal returns those values and the handler that called signal also returns them. The call to signal from the signaling unit that signaled the original condition returns the same values, and the signaling unit recovers as directed by those values." Restarts/The Dylan Reference Manual).

    It is not clear to me what happens if a restart handler performs a non-local exit targeting a location inside the unit where the restart handler was signal-ed.

    What is the added value of a restart handler as opposed to a regular handler; if we dispensed with restart handlers altogether (but not with regular handlers)? Would it make any difference as to the power or expressibility of the language?

    The restart mechanism is, in effect, a switch statements, whose selection condition is determined dynamically by code external to the function where the switch statement is defined. A restart signal can be emulated by a non-restart condition, but the restart mechanism provides two formal facilities that otherwise would have to be established by convention in order to achieve similar functionality:

    1. When a restart handler returns after having been signal-ed from within another handler, the rest of the code in the other handler is automatically skipped and the handler returns the values returned by the restart handler.
    2. A restart condition can be formally identified by its type. If there weren't a restart type, some other convention would need to be followed if it were desirable for restart conditions to be identifiable, e.g. for the purposes of listing them in the debugger's Recovery menu ("An interactive debugger ought to offer the user the ability to signal any restart for which a restart handler is applicable and to return if the condition's recovery protocol allows it. This could, for example, be done with a menu titled "Recovery." " Recovery Protocols/The Dylan Reference Manual)