[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue ASSERT-ERROR-TYPE Writeup

Status:       Proposal ERROR accepted 12/91

Issue: ASSERT-ERROR-TYPE

Forum: Cleanup

References: ASSERT (Condition System, Revision #18, p27)

Category: CHANGE

Edit history: 15-Mar-91, Version 1 by Pitman

Problem Description:

The condition system proposal says that ASSERT signals SIMPLE-ERROR

if the datum is omitted. This unnecessarily restricts an

implementation's options.

Proposal (ASSERT-ERROR-TYPE:ERROR):

Define that if the datum is omitted, ASSERT signals ERROR.

Test Case:

(HANDLER-CASE (HANDLER-CASE (ASSERT NIL) (SIMPLE-ERROR 1)) (ERROR 2))

Under Conditions System revision #18, this must return 1.

Under proposal ASSERT-ERROR-TYPE:ERROR, this might return either 1 or 2.

Rationale:

This leaves an implementation free to experiment with error types

specific to assertions. Since the user is free to specify whatever

type he needs, he can always work around any implementation-specific

type in any way he wants.

Current Practice:

In Symbolics Genera 8.1, the test case returns 1.

Cost to Implementors:

None. (Since SIMPLE-ERROR is a subtype of ERROR, no change is forced.

This just adds flexibility to implementations which want to do this

differently.

Cost to Users:

Little or none. There are probably very few people who are

specifically doing HANDLER-CASE for SIMPLE-ERROR with the intent

of specifically catching ASSERT.

Cost of Non-Adoption:

Implementations have their hands tied unnecessarily.

Benefits:

Aesthetics. Implementation flexibility.

Aesthetics:

Makes language more consistent in that this was the only place where

SIMPLE-ERROR was forced in a situation where the user wasn't supplying

a format string.

Discussion:

This issue was raised by Barrett several meetings ago, but was never

formally written up.

Pitman supports this.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.