This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 167: Add constructor for error objects

2012-11-29 02:13:36
WG1 - Core
alexshinn
major
cowan
wontfix
source
closed
2011-05-01 02:51:46
defect

(Email from Vincent Manis)

Problem: Raising arbitrary objects as exceptions has been found to be nasty in some other languages (Python and C++ in particular).

This one is a tad speculative, but I'm reluctant to encourage people to write things like (raise 4), because of course it doesn't respect any module boundaries. I think the intent with the descriptions of raise and raise-continuable was to allow exception hierarchies to be added in WG2 without constraining them here. I would suggest adding a new procedure:

(make-error-object message obj ...)

to creates the implementation-defined object error is supposed to create, and adding a sentence to the raise and raise-continuable entries that says "The effect of applying this procedure to an object not created via make-error-object is implementation-defined." This allows WG2 to do what it wants regarding exception objects, and to limit the types of exception objects allowed, without breaking anything in WG1. Error can be defined as:

(define (error message . objs) (apply make-error-object message objs))
resolutionfixed
statusnewclosed

We voted no.

resolutionfixed
statusclosedreopened
resolutionwontfix
statusreopenedclosed