[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Explaining raising conditions and defining condition types in the guile

From: swedebugia
Subject: Explaining raising conditions and defining condition types in the guile manual
Date: Fri, 9 Nov 2018 12:46:46 +0100


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:

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 <> of two custom condition-types used in guix:

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

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


I found this copyrighted explanation outside the manual <> 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 <>. 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.

reply via email to

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