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

Daniels.pa: Error Proposal #5 questions

Sorry if you've seen this already, but the first time I sent these out,
they got bounced back because Symbolics was off the air, so I'm
reposting the messages.

		-- Andy. --

     ----- Begin Forwarded Messages -----

Date: 24 Mar 86 18:07 PST
 From: Daniels.pa
Subject: Error Proposal #5 questions
To: CL-Error-Handling@SU-AI.ARPA
cc: Daniels.pa

1. I'm not sure what the second form of :report is supposed to look
like. Could I have an example of a use of it? (This is the case where
the report function goes to *standard-output*)

2. In previous versions, condition objects were immutable, i.e., all
slots were read-only. Is this still true?

3. If the condition signalled is of type SERIOUS-CONDITION, do you
always end up in the debugger if it isn't handled? The description of
SIGNAL implied that this may not be true.

4. In WARN, what is the "text of the warning" if a condition was passed
instead of a format string? (I assume that the way warnings are printed
is something like (FORMAT *ERROR-OUTPUT* "Warning: ~A." condition))

5. The definition of PROCEED-CASE states that a non-NIL name must
correspond to a defined proceed-function. This does not seem to be the
case, since INVOKE-PROCEED-CASE gives a way to get to that case. Which
is it?

6. The variable is DEFINE-PROCEED-FUNCTION differ from normal &OPTIONAL
parameters in that they to not allow a supplied-p parameter. Whay not go
ahead and make them the same as &OPTIONAL?

7. "If a named proceed function is invoked in a context in which there
is no active proceed case by that name, the proceed function simply
returns NIL." Does it still go ahead and collect parameters, or does the
test happen before any initial-value forms are evaluated?

8. If you hand INVOKE-PROCEED-CASE a name, does it simply unwind back to
the appropriate PROCEED-CASE, or does it call the proceed function? (The
answer is obvious if PROCEED-CASE names don't have to correspond to
proceed functions).

9. Since you've already define ILLEGAL-THROW and ILLEGAL-GO, it seems
like you should also have ILLEGAL-RETURN.

10. The list of standard condition types is incomplete. For example,
PARSE-NAMESTRING "signals an error if the hosts don't match." I couldn't
find an apporpriate condition to signal. It certainly isn't a
STREAM-ERROR, while simply using ERROR is distasteful -- it defeats the
purpose of having the type hierarchy.

This may be beyond the scope of the Error Proposal per se, but I believe
that there should be a well-defined condition for every place in CLtL
that indicates that an error is signalled. Of course, I don't mean that
we define a different condition type for each of these.

		-- Andy. --

     ----- Next Message -----

Date: 24 Mar 86 18:16:26 PST (Monday)
 From: Daniels.PA
Subject: Handler binding environment
To: CL-Error-Handling@SU-AI.ARPA
cc: , Daniels

What handler bindings are in effect while a handler is running?

There is an important invariant in the Symbolics and similar error
systems: when a handler is running the "handler binding stack" is popped
back to just after the binding that caused that handler to be called.
Nothing like this is mentioned in the proposal. I think it should be.

		-- Andy. --

     ----- End Forwarded Messages -----