A hasty response:

1) If you set the message to "foo" when you create the error object, then the posix-error:message procedure should return the same string. However, a simple "posix-error->string" could do some useful formatting.

2) I agree to changing the interface of errno-error to include the failing Posix function being called.

3) Rather than adopting srfi-170-error, I'd rather create another trivial SRFI and just put a reference to it here. As long as the name posix-error? is preserved, it won't matter if any changes are made to the SRFI. (Arthur, do you have a problem with making a SRFI that's vaguely dependent on a future SRFI in this way?)

On Fri, Jun 5, 2020 at 11:16 AM <xxxxxx@ancell-ent.com> wrote:

The disjoint error raising for non-system or library call errors, and using this in the Chibi Scheme sample implementation, as well as generally cleaning that up.

The only outstanding question is should the procedure name that failed be incorporated in the message, in addition to or instead being returned as part of the error's record. Currently, errors look like this, as displayed by Chibi Scheme:

{syscall-error #71 2 "called open: errno/ENOENT: No such file or directory" "open-file" ("bogus-filename" 1 438)}

As before, 2 is the numeric errno (and there is an unexported hash table to map between it and the define name like "errno/ENOENT"), the ending is a list of all the arguments handed to open-file. The system or library call that errored is just before the first ':', open in this example.

{SRFI-170-Error #72 "fname must be a string" "open-file" (1)}

By convention, I'm only handing the new srif-170-error procedure the relevant argument(s) that caused it to raise an error, in this case I asked it to open the fixnum 1.

The suggestion is to add to the message string "[called-procedure]: " in front of the above message string, i.e.:

"open-file called open: errno/ENOENT: No such file or directory"

"open-file: fname must be a string"

And how much of this to require in the SRFI text.

The new or changed stuff to incorporate in the SRFI HTML:

(errno-error errno procedure obj ...)    →    does not return       (procedure)

Becomes:

(errno-error errno procedure system-call-name obj ...)    →    does not return       (procedure)

To add the POSIX function name that errored. And while we're at it, procedure might be profitably renamed to procedure-name to emphasize how it's become the string of the name in instead of the raw procedure object.

Added is the following Scheme code; of course, I couldn't create an unsharable srfi-error disjoint type, so it's currently named for the particular SRFI:

(define-record-type SRFI-170-Error
    (make-srfi-170-error message procedure data)
    srfi-170-error?
(message srfi-170-error:message)
(procedure srfi-170-error:procedure)
(data srfi-170-error:data))

(define (srfi-170-error message procedure . data)
(raise (make-srfi-170-error
           message
           procedure
           data)))

So srfi-170-error?, rfi-170-error:message, srfi-170-error:procedure or srfi-170-error:procedure-name if we change the naming convention as suggested above, srfi-170-error:data, and make-srfi-170-error need to be added to the SRFI HTML.

- Harold