The SRFI 170 operations raise conditions that satisfy errno-error? when an errno is relevant, and ones that satisfy srfi-170-error? when errno is irrelevant (domain errors, often). in no case do they return normally with an error value. This allows the essentially imperative nature of Posix code to work correctly with explicit or implicit begin rather than a specialized construct.
Am Fr., 26. Juni 2020 um 16:44 Uhr schrieb <xxxxxx@ancell-ent.com>:
> And the step in-between of calling a POSIX function that only signals
> an error by setting errno, like getpwnam and getpwuid and their group
> versions. This is the severe danger, compared to calling a POSIX
> function, getting an error return, and then checking errno and getting
> a heisenbug value.
Indeed.
> Would not such a facility also have to be used by all the POSIX
> calls that are used in concert with SRFI 199 (and 198, for raising
> syscall-errors)? This could certainly be the Worse Is Better, New
> Jersey Style method to solving this very real problem. What would
> this look like?
I haven't followed the discussions for SRFI 170 and SRFI 198, but it
seems to me that exposing the errno concept is problematic. Better to
deliver the error value as part of the Scheme versions of the POSIX
functions. This can happen through different types being returned and
through Either wrappers coming from SRFI 189.
Marc