Email list hosting service & mailing list manager

The name "srfi-170-error" John Cowan (27 Jun 2020 14:51 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 14:57 UTC)
Re: The name "srfi-170-error" John Cowan (27 Jun 2020 18:01 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 20:57 UTC)
Re: The name "srfi-170-error" John Cowan (28 Jun 2020 03:38 UTC)
Re: The name "srfi-170-error" Lassi Kortela (28 Jun 2020 11:31 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (28 Jun 2020 12:49 UTC)
Re: The name "srfi-170-error" Lassi Kortela (28 Jun 2020 13:08 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (28 Jun 2020 13:54 UTC)
Re: The name "srfi-170-error" Arthur A. Gleckler (28 Jun 2020 15:21 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 15:19 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 15:22 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 16:02 UTC)
Generic C API error SRFI Lassi Kortela (27 Jun 2020 16:16 UTC)
Re: Generic C API error SRFI John Cowan (27 Jun 2020 18:23 UTC)
Re: Generic C API error SRFI Lassi Kortela (27 Jun 2020 20:45 UTC)
Re: Generic C API error SRFI hga@xxxxxx (27 Jun 2020 21:09 UTC)
Re: The name "srfi-170-error" John Cowan (27 Jun 2020 16:31 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 16:55 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 17:06 UTC)
Error collections Lassi Kortela (27 Jun 2020 17:08 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 17:20 UTC)

Re: The name "srfi-170-error" hga@xxxxxx 27 Jun 2020 16:02 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Saturday, June 27, 2020 10:22 AM
>
> > Last year Lassie and I
>
> Woof! :-)

Oops, I knew I'd make that mistake sooner or later
https://en.wikipedia.org/wiki/Lassie).

>> were thinking we should create a Grand Unified
>> Scheme Error System, inspired in part by the neat system of coding
>> Oracle uses in its error reporting.  This anticipated transition
>> suggests we should work on it ASAP.
>
> Good call.

Thanks, let's do it.

> Since SRFI 198 is very Unix-specific, we should perhaps submit a new
> SRFI about the generic framework.

I agree, 198 has unique APIs like errno-string (which you propose to
enhance, although that's not 198 API visible), and errno-name, which
gives you the define name, e.g. ENOENT.

> However, it might be a good idea to take the Windows API (and perhaps
> other OS error APIs) into account in 198.

Is there any 198 API difference that will be visible besides
errno-name?  Which on Windows could just return an empty string, or
maybe something concise that's Windows meaningful?

- Harold