Date: Sunday, June 14, 2020 3:56 PM
Which is currently the Chibi-Scheme sample implementation's disjoint record type used by errno-error, which is the procedure called when a system or library call fails. I just realized this record should either be put in another SRFI as recently and some time ago discussed, or renamed to something like "[whatever]SRFI-170-[whatever]" like the current "SRFI-170-Error", because other SRFIs will also be generating syscall errors.
Come to think of it, errno-error shouldn't be in the namespace, nor the analogous srfi-170-error or whatever it ends up being named. Users of the SRFI need to access the records they return, and will want to catch and rethrow the records, but shouldn't be directly calling these functions that construct and throw the records.
errno-error is never handed a message string, it constructs it from scratch starting with the official message associated with the errno, I'm suggesting enhancing that string further. The new in the Chibi Scheme implementation srfi-170-error is handed a message, but following the format of errno-error, the calling procedure is a separate argument, which also I feel is cleaner. And I'm suggesting enhancing it in the same way as I'm suggesting with errno-error, which would change it, which you'd like to avoid.
I am okay with changing to take an additional argument. Scsh code is not going to be directly portable to SRFI 170, not by a long way.
Good, and I'll incorporate this string into the error message, but agree with you that:
Adding more machinery that would have to be manually invoked to get a slightly more intelligible error message when the procedure name string is part of the error sounds like work a user would likely not bother to do.
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?)
We've previously discussed creating a general error handing SRFI, a bit like how timespecs have already been broken out. My issue here is that I'd like to specify a minimum of details to be reported by SRFI 170 for its own errors, and think it might be a good idea to specify the specifics, including the format of the message string. Especially if we're going to be rigid like I'm proposing to do with errno-error.
I'm okay with adding the arguments procedure-name and syscall-name as well as the name associated with the errno, but not okay with specifying a rigid format for them. I'd rather have them be free format so they can be internationalized without worrying about breaking code that attempts to parse them, since such code will go beyond the standard.
Yes, had forgotten about that. Instead, might we specify something like:
The error string should make clear which SRFI 170 procedure called the failing syscall, the specific failing syscall, the errno define name, and the error string associated with the errno. In English, something like "open-file called open: errno/ENOENT: No such file or directory" would satisfy this requirement.
- Harold