[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Error proposal questions
- To: kmp@scrc-stony-brook.arpa
- Subject: Error proposal questions
- From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
- Date: Wed, 29 Jan 86 22:45:31 GMT
- Cc: cl-error-handling@su-ai.arpa
I have some questions about the proposal distributed in Boston. They're
all pretty trivial, and I hope I haven't just missed some mail that answers
everything, but here they are:
(1) DECLINE is defined only implicitly, but by analogy with PROCEED
I assume it's a function rather than a macro.
(2) What happens if DECLINE or PROCEED is called with some condition
other than the one that was signalled? Ditto for proceed functions.
(3) How do the proceed-cases get into a condition? Does SIGNAL-CASE
SETF this field? If so, what happens if this condition is later
reused in a situation where the proceed-cases are invalid?
(4) It seems that types like CONDITION and ERROR will have condition-
reporters, but the proposal doesn't define any. Nor does it say
what their default handlers, if any, will do.
(5) Are default-handlers meant to be inherited, a la report functions?
(6) What does CONDITION-DEFAULT-HANDLE do if there's no default handler?
(7) Is the 'type' argument to CATCH-CONDITION meant to be evaluated?
The answer appears to be "no", but if the call to IGNORE-CONDITION
in the description of IGNORE-ERRORS is meant to be CATCH-CONDITION
then the answer would be "yes".
(8) Is the ABORT condition type a subtype of ERROR?
(9) Is the reference to DEFINE-PROCEED-TYPE in the description of
PROCEED meant to be a reference to DEFINE-PROCEED-FUNCTION?
-- Jeff