[Top][All Lists]

[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

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
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
of such a feature cannot be portable, but should be trivial in any one


John 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]