posix-error and a list of scheme procedure arguments Shiro Kawai (15 Aug 2020 07:55 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (15 Aug 2020 11:16 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (15 Aug 2020 12:09 UTC)
Synthetic errno values Lassi Kortela (15 Aug 2020 13:10 UTC)
Re: Synthetic errno values John Cowan (15 Aug 2020 15:19 UTC)
Re: Synthetic errno values Lassi Kortela (15 Aug 2020 15:34 UTC)
Re: Synthetic errno values hga@xxxxxx (15 Aug 2020 16:02 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 07:58 UTC)
Re: Synthetic errno values hga@xxxxxx (16 Aug 2020 12:39 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 13:07 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 01:12 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 02:30 UTC)
Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 02:44 UTC)
Re: Split SRFI 198 from generic debugging/inspection? Lassi Kortela (16 Aug 2020 09:06 UTC)
Re: Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 13:01 UTC)
Matching what other languages give in SRFI 170 errors Lassi Kortela (16 Aug 2020 13:47 UTC)
Re: Matching what other languages give in SRFI 170 errors Marc Nieper-Wißkirchen (17 Aug 2020 06:11 UTC)
Re: Matching what other languages give in SRFI 170 errors Lassi Kortela (17 Aug 2020 10:10 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 08:55 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (16 Aug 2020 09:02 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 09:11 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 09:44 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 10:20 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:29 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 12:18 UTC)
Continuation marks and SRFI 198 Lassi Kortela (16 Aug 2020 11:29 UTC)
Re: Continuation marks and SRFI 198 Marc Nieper-Wißkirchen (16 Aug 2020 12:52 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:17 UTC)
Passing symbols to say where errors came from? Lassi Kortela (16 Aug 2020 11:21 UTC)
Re: Passing symbols to say where errors came from? John Cowan (17 Aug 2020 17:07 UTC)
Re: Passing symbols to say where errors came from? hga@xxxxxx (17 Aug 2020 18:44 UTC)
Re: Passing symbols to say where errors came from? Shiro Kawai (17 Aug 2020 22:06 UTC)
Re: Passing symbols to say where errors came from? Marc Nieper-Wißkirchen (18 Aug 2020 06:09 UTC)

Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen 15 Aug 2020 11:16 UTC

Am Sa., 15. Aug. 2020 um 12:58 Uhr schrieb <xxxxxx@ancell-ent.com>:

> The theory I've been working on is that it's the responsibility of the calling Scheme procedure to catch such thrown errors and turn them into proper SRFI 170 errors.  Like too many other details, I've fudged this for the SRFI 170 Chibi Scheme sample implementation, its automagic FFI only throws type check errors, I just mechanically duplicate that checking in the calling Scheme procedure.  An error like EPERM, which of course can only be detected at the C level, is done through an error return value and then (improper) querying of errno.
>
> Having 'scheme-procedure be #f deprives the user of valuable information that could make debugging quite a bit harder, although if you fake the values for the 'args key it probably won't be too bad.
>
> One alternative that occurs to me is that you could pass to the C code the calling Scheme procedure, or as you note, examine the stack to get that and the args.

Depending on the implementation there may be no stack entry. And you
probably don't want the overhead to pass the called Scheme procedure
and its arguments in the generic case where there is no error.

The information about the called procedure and its arguments is
certainly useful for debugging, but it is probably best to leave it up
to the implementation how (and if) this information is provided (at
least until we have some general consensus about debugging
facilities).

Marc