Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 06 Jun 2020 17:25 UTC
Re: Add further conversions between data-directed and code-directed programming idioms John Cowan 06 Jun 2020 23:27 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 09:13 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Lassi Kortela 07 Jun 2020 12:18 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 13:25 UTC
Low-level vs high-level exceptions Lassi Kortela 07 Jun 2020 13:59 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 07 Jun 2020 15:45 UTC
Re: Low-level vs high-level exceptions John Cowan 08 Jun 2020 14:29 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:36 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:52 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 09 Jun 2020 06:11 UTC
Re: Low-level vs high-level exceptions Wolfgang Corcoran-Mathe 09 Jun 2020 13:03 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 00:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 10:37 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 14:57 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:31 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:42 UTC
Re: Low-level vs high-level exceptions John Cowan 16 Jun 2020 01:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 16 Jun 2020 07:33 UTC

Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 07 Jun 2020 15:45 UTC

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.