Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-WiÃkirchen 07 Jun 2020 13:25 UTC
Am So., 7. Juni 2020 um 14:18 Uhr schrieb Lassi Kortela <firstname.lastname@example.org>: > 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.