Am So., 7. Juni 2020 um 14:18 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> Sounds quite dangerous. Signals and threads go together like diet coke
> and mentos :)

I tried this experiment a few weeks ago with my children. It works!

> As one pitfall, there must be a decision in which thread the signal
> handler is run and whether or not other threads are stopped. Some OSes
> even have a separate signal stack. I'm sure there are many more footguns
> involving I/O interruptions, continuations and FFI for starters.

Modelling synchronous signals like SIGSEGV as Scheme exceptions may
make more sense if these exceptions are continuable.

> > but I agree with you that catching every exception by
> > default can be very dangerous.
>
> +1

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". (*)

Even when such an exception is caught, there is not much portable code
do with it anyway (maybe except for logging it and reraising it; but
even logging may be dangerous when it is not clear how severe the
exception is that has been caught).

The advantage of (*) is also that the danger inherent in the
else-clause in the standard guard form would be diminished.