Am Mi., 8. Juli 2020 um 21:47 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-07-08 16:27 +0200, Marc Nieper-Wißkirchen wrote:
> > While it is true that this syntax can always be added later (as can,
> > in principle, every part of this SRFI), it would be unfortunate to
> > leave out exactly 'either-guard' because it will certainly be used
> > much more often than a number of other procedures in this SRFI and
> > sets a clear style for idiomatic code:
>
> The more I think about a form for converting exceptions to Eithers,
> the more there seems to be something fundamentally flawed about the
> idea.  The exception-based and data-directed approaches to
> error-handling seem to me to be very difficult to reconcile, at
> least in the exception->data direction; you're taking an exception,
> possibly asynchronous, signalled outside the normal flow of control
> of a program, and jumping back into that flow with a datum encapsulating
> that exception.  In contrast, going the other way (e.g. by raising
> the payload of a Left) is simple and idiomatic.  This suggests to
> me that converting exceptions to Eithers, as an idiom, is the Wrong
> Thing.

I don't think so (at least as long not arbitrary exceptions but only
well-defined are caught).

The guard form or any C++/Java/Python exception handler that does not
reraise the caught exception does this exactly, namely turning an
exception into data.

This is certainly an important language construct.

One can also see it as protocol conversion, from exception-style
programming to a C-style programming where the return value decides
about success:

(define (delete-file-and-return-success filename)
  (guard (exc ((file-error? exc) #f)) (delete-file filename) #t))

The point of Eithers is to reason about success and failure (with
payloads) in a data-driven style. Many existing APIs, however, use
different code paths through exceptions and not data. We want an
adapter to the world of Eithers.

We can put Eithers in data structures (e.g. to create a list of
results). We cannot put raised exceptions in lists. This is just
another use case.