#

## 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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.