Explaining raising conditions and defining condition types in the guile manual

Explaining raising conditions and defining condition types in the guile manual

[swedebugia]

Hi

I'm digging deep in the source of Guix ATM.

Reading in the Guile manual I did not find a section describing this use 
of exceptions:

(raise (condition (...

^ used by Ludo here: 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/mapped-devices.scm#n145

It seems elegant and nice and maybe a generic example based on it could 
fit somewhere in the manual. :)

By searching for "&message" i at last found the implementation detailing 
r6ns exceptions in the guile manual but there were no examples or prose 
explaining what they are good for.

I also found this definition tucked away in a corner of the guix source 
<http://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n806> of 
two custom condition-types used in guix:


(define-condition-type &error-location &error
   error-location?
   (location  error-location)) ;<location>

(define-condition-type &fix-hint &condition
   fix-hint?
   (hint condition-fix-hint))                      ;string

--

I found this copyrighted explanation outside the manual 
<https://www.scheme.com/tspl4/exceptions.html> though:


      Section 11.2. Defining Condition Types

While a program may pass raise or raise-continuable any Scheme value, 
the best way to describe an exceptional situation is usually to create 
and pass a /condition object/. Where the Revised^6 Report requires the 
implementation to raise exceptions, the value passed to the current 
exception handler is always a condition object of one or more of the 
standard /condition types/ described in Section 11.3 
<https://www.scheme.com/tspl4/exceptions.html#g150>. User code may 
create a condition object that is an instance of one or more standard 
condition types or it may create an extended condition type and create a 
condition object of that type.

Condition types are similar to record types but are more flexible in 
that a condition object may be an instance of two or more condition 
types, even if neither is a subtype of the other. When a condition is an 
instance of multiple types, it is referred to as a /compound condition/. 
Compound conditions are useful for communicating multiple pieces of 
information about an exception to the exception handler. A condition 
that is not a compound condition is referred to as a /simple condition/. 
In most cases, the distinction between the two is unimportant, and a 
simple condition is treated as if it were a compound condition with 
itself as its only simple condition.
-- 
Cheers
Swedebugia

Re: Explaining raising conditions and defining condition types in the guile manual

[swedebugia]

On 2018-11-09 12:46, swedebugia wrote:
> Hi
>
> I'm digging deep in the source of Guix ATM.
>
> Reading in the Guile manual I did not find a section describing this 
> use of exceptions:
>
> (raise (condition (...
>
> ^ used by Ludo here: 
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/mapped-devices.scm#n145
Found it!

Tucked deep in 
https://www.gnu.org/software/guile/manual/html_node/SRFI_002d35.html#SRFI_002d35

>
> It seems elegant and nice and maybe a generic example based on it 
> could fit somewhere in the manual. :)

There is actually a generic example in the link above :)

Cheers

Re: Explaining raising conditions and defining condition types in the guile manual

[swedebugia]

On 2018-11-09 12:46, swedebugia wrote:
> Hi
>
> I'm digging deep in the source of Guix ATM.
>
> Reading in the Guile manual I did not find a section describing this 
> use of exceptions:
>
> (raise (condition (...
>
> ^ used by Ludo here: 
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/mapped-devices.scm#n145
Found it!

Tucked deep in 
https://www.gnu.org/software/guile/manual/html_node/SRFI_002d35.html#SRFI_002d35

>
> It seems elegant and nice and maybe a generic example based on it 
> could fit somewhere in the manual. :)

There is actually a generic example in the link above :)

Cheers

Re: Explaining raising conditions and defining condition types in the guile manual

[Ludovic Courtès]

Hello,

swedebugia <swedebugia@riseup.net> skribis:

> Reading in the Guile manual I did not find a section describing this
> use of exceptions:
>
> (raise (condition (...
>
> ^ used by Ludo here:
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/mapped-devices.scm#n145
>
> It seems elegant and nice and maybe a generic example based on it
> could fit somewhere in the manual. :)
>
> By searching for "&message" i at last found the implementation
> detailing r6ns exceptions in the guile manual but there were no
> examples or prose explaining what they are good for.

‘raise’ is from (srfi srfi-34) and ‘condition’, ‘&message’, and friends
are from (srfi srfi-35):

  https://gnu.org/software/guile/manual/html_node/SRFI_002d34.html
  https://gnu.org/software/guile/manual/html_node/SRFI_002d35.html

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.  :-)

HTH!

Ludo’.

Re: Explaining raising conditions and defining condition types in the guile manual

[John Cowan]

On Fri, Nov 9, 2018 at 11:10 AM Ludovic Courtès <ludo@gnu.org> 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        cowan@ccil.org
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