by Stephan Houben
This copy of the SRFI 23 specification document is distributed as part of the Racket package srfi-doc.
The canonical source of this document is https://srfi.schemers.org/srfi-23/srfi-23.html.
This SRFI is currently in final status. Here is an explanation of each status that a SRFI can hold. To provide input on this SRFI, please send email to
srfi-23 @nospamsrfi.schemers.org. To subscribe to the list, follow these instructions. You can access previous messages via the mailing list archive.
R5RS Scheme requires certain operations to signal an error when they fail. "Signalling an error" means that implementations must detect and report the error. Moreover, R5RS encourages, but not requires, implementations to signal an error in many more circumstances.
However, there is no direct way for the Scheme application programmer to report an error that occured in his or her own application. This means that Scheme procedures created by applications or libraries are in this respect not on equal footing with procedures provided by the Scheme system.
Many Scheme systems already provide a mechanism that allows application code to report an error. At least the following implementations support such a mechanism: Bigloo, Guile, MIT Scheme, PLT Scheme, RScheme, Scsh, SCM, all implementations supported by SLIB. Of these implementations, the following have an error mechanism compatible with this SRFI: Guile, MIT Scheme, PLT Scheme, RScheme, Scsh. The implementation in SLIB has a different name than the one proposed in this SRFI.
To summarise, many implementations already have the error reporting mechanism described in this SRFI and others are easily made compatible with this SRFI. This shows that the proposed mechanism is considered useful and that it is easy to implement in most major implementations.
The following procedure should be provided:
[<arg1> [<arg2> ...]])
The argument <reason> should be a string.
error will signal an error,
as described in R5RS, and it will report the message <reason>
and the objects <arg1>, <arg2>, ....
What exactly constitutes "signalling" and "reporting" is not prescribed, because of the large variation in Scheme systems. So it is left to the implementor
to do something reasonable. To that end, a few examples of possible behaviour
erroravailable to other threads in some way. See the
thread-join!mechanism in SRFI-18 on how this could be done.
An implementation might report more information than just <reason> and <arg1>... . For instance, it might report the procedure name in which the error occurred or even print a stack trace. However, this will require additional support in the Scheme implementation.
erroris a procedure
It is conceivable to allow
error to be a special form,
such as a macro, rather than a procedure. This might make providing
information such as the source code location easier. This possibility
has been considered, but rejected, for two reasons.
erroraccepts a variable number of arguments, it could occasionally be useful to use
error. However, this is not possible if
errorwas allowed to be a special form.
erroris currently a procedure in all Scheme implementations mentioned above, it doesn't seem all that worthwhile to allow it to be a special form.
An implementation that works in almost any R5RS Scheme is the following:
(define (error reason . args) (display "Error: ") (display reason) (for-each (lambda (arg) (display " ") (write arg)) args) (newline) (scheme-report-environment -1)) ;; we hope that this will signal an error
This implementation has a flaw, namely, in many implementations this will actually print 2 messages.
message, followed by
scheme-report-environmentgetting an invalid argument.
This might be confusing to the user.
The SLIB procedure
slib:error works like the
procedure described in this document.
Thus, when SLIB is loaded,
error can be defined as:
(define error slib:error)
If SRFI 18 is supported, it is allowed
(but not required) to implement
terms of the exception mechanism of SRFI 18.
(define (error reason . args) (raise (make-error-exception reason args)))
make-error-exception is implementation dependent.
Copyright (C) Stephan Houben (2001). All Rights Reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.