IMO if they are not based on errno they should not be syscall-error objects but some other kind of objects.

I agree that the mesage string set up by errno-err  should include the name.  But set it up however you want, and I'll fix the docs accordingly.

On Tue, Jun 2, 2020 at 7:00 PM <> wrote:
One thing that's completely missing from the Chibi Scheme implementation since the old scsh based error specification didn't include, it is raising errors not based on POSIX errors AKA errnos.  Such as handing a procedure an argument of the wrong type, instead it's faked with the closest matching errno, but that's of course a lie, and I don't like lying to users.  Since exception specification is being returned to the SRFI, it would be good to fix this, and I'm willing to go through all the errors and fix them up, that's easy mindless mechanical work.

Don't remember why this implementation's record "procedure" slot has the actual procedure rather than the string of its name; again, perhaps from the original specification.  That too can be easily fixed, especially if there are no standard ways to get that metadata given the procedure.

One item from the TODO.txt that I think should be added now that the SRFI is not silent on how to raise exceptions is a string with the name of the system or library call that failed, and the errno define name, perhaps in the form "errno/2big" (already did that block of work...).  Returning just the message string is infuriating because all the POSIX and man page documentation refer to the define names, and it can be extremely obnoxious to manually map the raw errno number to the right define in a system like Linux (OpenBSD of course makes it nearly trivial, /usr/include/errno.h is short, and just includes sys/errno.h which has them all in numerical order, but it would still be more convenient to return the define name).

- Harold

----- Original message -----
From: John Cowan <>
Date: Tuesday, June 02, 2020 9:21 AM

Currently SRFI 170 requires that if its procedures fail, they must raise an exception, but provide no way to distinguish the condition object from all other kinds of condition objects.  These procedures are available in the Chibi implementation, but aren't exposed.  In IMHO decreasing order of importance, they are:

1) syscall-error? detects a SRFI 170 condition object and can be used in a guard-expression.

2) syscall-error:errno, syscall-error:message, syscall-error:procedure, syscall-error:data are accessors for the condition object.  Note that syscall-error:procedure returns the actual procedure, not its name (as a symbol); this seems rather useless to me.

3) errno-error lets you create your own condition object and raise it immediately. It's an error to use this with an unknown errno, since it uses strerror() to convert from errno values to strings.

4) make-syscall-error lets you create your own condition object without raising it.

Scsh exposes only group 3.  For the moment, I am adding groups 1 and 2, which are needed for error handling, and group 3, which is needed for error reporting in any future extensions to this SRFI.

John Cowan