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