[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about error handling
- To: LANDER%cs.umass.edu@CSNET-RELAY.ARPA
- Subject: Questions about error handling
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Sun, 29 Jun 86 01:06 EDT
- Cc: CL-ERROR-HANDLING@SU-AI.ARPA
A CONDITION-CASE is invisible to SIGNAL if it does not name condition
types relevant to the condition being signalled.
In the case of locally bound handlers, you should check each CONDITION-BIND
using TYPEP. That is, type inclusion works. For example, if you bound
a handler for ERROR, it will see more specific errors such as
UNBOUND-VARIABLE. If you bind a handler for a specific type such as
UNBOUND-VARIABLE, the handler will not get a shot at more general errors
such as ERROR.
In the case of default handlers, they are to be tried in order starting
with the default handler for the most specific type (if any) and working
out. eg, if a SIMPLE-CONDITION is signalled and no bound handler is
found, then then a default handler for SIMPLE-CONDITION will be tried.
If that declines, then the default handler for CONDITION will be tried.
I'll be circulating a proposal which has these and other issues clarified
in the near future. There is behind-the-scenes interaction going on right
now because Alan Bawden has sent me a list of criticisms about the fuzziness
of proposal 5. I'm producing a revised proposal that will hopefully
make him happy, clarify the things you and Daniels have asked about, and
will deal with other issues I ran into in producing the portable
implementation. If I didn't answer some question or if you have other
questions as you go, please let me know. Thanks.