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)

Generic C API error SRFI Lassi Kortela 27 Jun 2020 16:16 UTC

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

No problem :)

>> 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?

I'd wager most mature C error APIs conform to this general format:

#define MY_ERROR_CODE_FOO 1234
...
const char *my_strerror(int my_error_code);

Hence the generic Scheme framework could be like:

- Name of C API that caused the error (as a symbol or string)
- Name of C constant for the error code (as a symbol or string)
- Integer C constant for the error code (as a fixnum)
- Which error collection this error came from (as a symbol)
- Error message (in English, or a localized one if English not available)
- Localized error message (where available)

The error collections could be, by convention:

- errno or unix (the name "posix" would be misleading)
- winapi or windows or win32
- winsock (Windows Sockets errors are different from general WinAPI ones)
- sqlite (https://sqlite.org/c3ref/errcode.html)
- ...

> Which on Windows could just return an empty string, or
> maybe something concise that's Windows meaningful?

The `errno-name` in SRFI 198 returns the C identifier as a Scheme
symbol. WinAPI (and SQLite, etc.) errors also have such C identifiers.
It might be enough for SRFI 170 to simply use the generic error
framework as-is and give errno/unix as the error collection from which
its errors come.