Adding SRFI 198 to the CC list, since this implicates its design and use.

Date: Saturday, August 15, 2020 2:54 AM

In johnwcowan/srfi-170 repo, the posix error object is required to include scheme procedure name and scheme procedure arguments.

If a posix error is only thrown from srfi-170 APIs, it is clear where those information comes from. However, it can be raised from a different places---e.g. an implementation's runtime may be written partially in C and one of such runtime can throw an error on EPERM. The runtime written in C may be called from multiple Scheme procedures and may not have these information.

- Shall we limit posix error to be thrown only from srfi-170 API (or similar ones that the correspondence of Scheme procedures and underlying POSIX call is clear)?

- Or shall we allow these information to be #f when unavailable?

In Gauche, POSIX errors are mapped to <system-error> object regardless of where it occurs, and those info isn't readily available (It can inspect Scheme VM stack to retrieve those info, though.)

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.