Next: exceptions interop, Previous: exceptions handling, Up: exceptions [Contents][Index]
who must be a string or a symbol or #f
. message must be a string. The
irritants are arbitrary objects.
These procedures raise a non–continuable exception. The error
procedure should be called
when an error has occurred, typically caused by something that has gone wrong in the interaction of
the program with the external world or the user. The assertion-violation
procedure should be
called when an invalid call to a procedure was made, either passing an invalid number of arguments,
or passing an argument that it is not specified to handle.
The who argument should describe the procedure or operation that detected the exception. The message argument should describe the exceptional situation. The irritants should be the arguments to the operation that detected the violation.
The condition object provided with the exception has the following condition types:
#f
, the condition has condition type &who
, with who as
the value of its field. In that case, who should be the name of the procedure or entity that
detected the exception. If it is #f
, the condition does not have condition type
&who
.
&message
, with message as
the value of its field.
&irritants
, and its field has as
its value a list of the irritants.
Moreover, the condition created by error
has condition type
&error
, and the condition created by assertion-violation
has condition type &assertion
.
(define (fac n) (if (not (integer-valued? n)) (assertion-violation 'fac "non-integral argument" n)) (if (negative? n) (assertion-violation 'fac "negative argument" n)) (letrec ((loop (lambda (n r) (if (zero? n) r (loop (- n 1) (* r n)))))) (loop n 1))) (fac 5) ⇒ 120 (fac 4.5) error→ exception &assertion (fac -3) error→ exception &assertion
An assert
form is evaluated by evaluating <expression>. If <expression> returns a
true value, that value is returned from the assert
expression. If <expression> returns
#f
, an exception with condition types &assertion
and &message
is raised.
The message provided in the condition object is implementation–dependent.
Next: exceptions interop, Previous: exceptions handling, Up: exceptions [Contents][Index]
This document describes version 0.1.0-devel.1 of MMCK Exceptional Conditions.