[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Explaining raising conditions and defining condition types in the gu
From: |
John Cowan |
Subject: |
Re: Explaining raising conditions and defining condition types in the guile manual |
Date: |
Fri, 9 Nov 2018 14:16:16 -0500 |
On Fri, Nov 9, 2018 at 11:10 AM Ludovic Courtès <address@hidden> wrote:
The R6RS exception mechanism is close to but different from SRFI-34/35,
> and I presume the R7RS mechanism is likewise close to but different from
> both R6 and SRFI-34/35. :-)
>
Sorta. The *exception* system is the same as in R6RS except that `error`
does not use the `who` argument (staying compatible with SRFI 23).
But no *condition* system are defined, so that implementations
can keep their native condition systems. (Racket wound up with two
condition systems, native and R6RS.)
Consequently, portable programs can catch a condition with `guard`
or `with-exception-handler`, but can't discriminate between different
exceptions, with three, umm, exceptions:
`read-error?` says if a condition reflects an error is signaled by `read`
indicating bad S-expression syntax.
`file-error?` says if a condition reflects a file that cannot be opened or
deleted.
These cases are precisely those where R5RS says "an error must be signaled".
(Well, there is also passing a bad number to `scheme-report-environment`,
but who cares.)
Also, `error-object?` returns true on conditions created and raised by
`error`,
but may return true on other conditions as well, implementation-dependently.
I'm hoping to add more predicates of this type for R7RS-large. The
implementation
of such a feature cannot be portable, but should be trivial in any one
Scheme.
--
John Cowan http://vrici.lojban.org/~cowan address@hidden
Newbies always ask:
"Elements or attributes?
Which will serve me best?"
Those who know roar like lions;
Wise hackers smile like tigers. --a tanka, or extended haiku