If we were defining exceptions de novo, this would be a very useful distinction, more or less comparable to the Java distinction between Exception and Error. However, making it now is not only backwards incompatible with R7RS-small, but is a big non-portable change in an area where implementers have historically pushed back on any attempt at systematization.

Therefore, I am going to go with (exception->either pred thunk), which invokes thunk and returns its values wrapped in a Right, unless an exception satisfying pred occurs, in which case the exception is wrapped in a Left and returned.

Completely untested implementation:

(define (exception->either pred thunk)

(with-exception-handler

(lambda (e)

(if (pred e) (left e) (raise-continuably e)))

(lambda () (call-with-values thunk right))))

On Sun, Jun 7, 2020 at 11:46 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Am So., 7. Juni 2020 um 15:59 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > It may make sense to define a class of exceptions that cannot be
> > caught by user provided handlers. This can include all exceptions a
> > Scheme system raises where the standard just says "... it is an
> > error". (*)
>
> > The advantage of (*) is also that the danger inherent in the
> > else-clause in the standard guard form would be diminished.
>
> This could also be approached from the other direction by defining a new
> `guard%` that catches absolutely everything, and implement the standard
> `guard` so that it only catches "normal" high-level exceptions. If
> necessary for conformance, the low-level exceptions can be called by
> some other name than "exception".

Guard is defined in terms of `with-exception-handler', so
`with-exception-handler' couldn't catch the "unnormal" low-level
exception either. But again, this may be a good thing. Catching
low-level exceptions with implementation-specific handlers makes much
more sense.