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.