I'm concerned about trapping *all* condition objects (and there is no standard hierarchy of condition types).  There are two particularly bad cases, asynchronous exceptions and exceptions that the implementation relies on not being caught.

In a Scheme that transforms Posix signals into exceptions, it would be impossible to terminate or stop a process while inside this feature by SIGINT or SIGSTOP (though SIGQUIT and SIGTSTP will still work), nor will SIGBUS be very useful if trapped.  If there were a reliable signal-from-exception? predicate, that would help, but there isn't.  Similarly, an implementation that raises an out-of-memory exception from the GC may find it being swallowed if the GC runs on any random thread rather than its own.

In Java at least, a thread is killed (by itself or another thread) by raising an instance of ThreadDeath class.  This can be observed by a try-finally expression in order to execute the thread's finalizers if any.  But if it is caught without being re-raised, the Java runtime will not properly kill the thread.  That would keep all threads alive while such a block was running.



On Sat, Jun 6, 2020 at 1:25 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
* Add a procedure

(either <thunk>)

that calls thunk and returns its values wrapped into a Right except
for when <thunk> raises an exception.  In that case, wrap the error
object in a Left and return it.

The "inverse" of this procedure is `either-ref'. The name "either" is
probably not the best one.

Implementation:

(define (either thunk)
  (guard (c (else (left c))) (call-with-values thunk right)))

* Add maybe-let* that works like and-let* but can handle multiple
values and can accept #f values.

I would be willing to contribute an implementation in case Wolfgang
doesn't want to.