For many purposes, ``pre-substitution'' is a plausible strategy. There may be, in some calculations, a particularly neat way of saying how to complete the arithmetic domain. For example one may wish to change 0/0 from a NaN to 1, temporarily. A language design could allow for stating (in some compact manner), the notion that ``should the calculation of 0/0 be attempted, use this answer: 0.'' This should be implementable cleanly on each platform.
Some alternative for specification of altered control-flow is usually available, but often of a highly restricted nature. Direct user-level specification of a return to the scope and location of the exception might not be available, and would certainly involve language, compiler, and platform considerations. and it might not be possible to impose upon all implementations (cf. Scheme continuations...).
Linguistically, what do these non-presubstitution specifications look like? The tools are vaguely reminiscent of the rounding mode discussion earlier, but rounding modes do not require discussion of handlers.
[(Aside on integer divide by zero?)]
A. there could be compile-time instructions:
with fp_arith_traps=disabled {execution}, or ...
with fp_arith_traps=enabled
( {execution}, {replacement-execution})
B. preferably the possibility of setting flag to disabled
or enabled could be done at RUN TIME:
then running ``the same piece of code''
with fp_arith_traps=switch
<execution>
<replacement-execution>
with rounding_mode=to_zero <execution>
At compile-time there would some hope that the compiler would emit code for serial execution unless it could prove the impossibility of exceptions. An alternative is perhaps to emit ``fixup'' code in case an exception occurs. This would probably be rather ticklish.
What about examining sticky flags at return from a subroutine F to ask ``did an un-trapped exception occur during the execution of F?''
Of course if the return process reset the flags this would be pointless.
The RISC tradition for call/return is to have minimal linkages for inexpensive function call/return, but with the prospect of tacking on more prolog/ epilog. The CISC tradition (e.g. call on VAX) is heavy-weight.
The subroutine is a great invention and should be used and supported. Yet many programmers taught that subroutines are inefficient and to be avoided. Just as C++ programmers are told not to use object-oriented features. Go figure..
on-units in PL/I, Try-Catch in Java. Here's another more comprehensive view of ``conditions'' in a language.