The most common use of exceptions is to provide a kind of safety net to deal with errors before they become major problems resulting from the propagation of erroneous values or from wholesale crashes. Some would argue that exceptions should only be used for such purposes, despite the temptation they present to some programmers to use them more as a variant goto.
As hinted near the end of Chapter 4 [WEBeye: A Case Study], exceptions are not as important in SETL as they might be in other languages. It is certainly true that there are various ways of crashing a SETL program, ranging from systemic errors such as running out of memory to data-oriented errors such as trying to read a non-numeric denotation as a number. The emergence of a SETL type system is likely to introduce more, such as the possibility of constraint violations and other errors.
But all these exigencies can be handled gracefully by isolating the vulnerable code (the kind of code that would normally be placed under the protection of an exception handler) in its own little process attached to the parent through a pump stream. If the child crashes, the parent merely sees an end-of-file condition, which does not crash the parent. The subprocess also offers a level of protection against denial-of-service attacks in which clients try to hold connections open indefinitely (see Section 3.3.1 [Time-Monitoring Server]).
However, I make these observations not in order to demonstrate that exception-handling is superfluous, but merely to suggest why its absence has not been a tremendous burden. The fact remains that a good exception-handling facility would be a positive addition to SETL. I will not attempt to lay out a detailed design here, but would like to note that resumption semantics need not be seriously contemplated for SETL. How exactly exceptions are to be identified probably should not be specified until a satisfactory type system has been designed, but the potentially delicate semantics of the initial transfer of control are already equivalently met in the situation where an expr block is contained within an expression--a tuple former, for example--and that expr block executes a goto out of the expression instead of yielding a value.