I have mostly avoided dealing with the condition system all my years
with lispms and now with the new condition system--the primary reason
being that it was very difficult to find out what condition had been
signalled that I needed to catch (perhaps it isn't and I was/am just
ignorant of how), and it's 'name' so that I could use it with
condition-case.
anyway, I would like to know how (if it's possible) to find out
programmatically (or is that automagically) what condition is
signalled when some piece of code does so.
at the moment, I'm getting a ABORT or some sort signalled out of
CLIM's accepting-values, but if I use handler-case to try to grab it,
I seem to have the wrong name or something. so what I need today is to
know what gets signalled when I click on the <abort> exit-box. for the
future I'd like to know how to find ANYTHING that's signalled.
-- clint
--
Clint Hyde "Give me a LispM or give me death!" -- anonymous
Advanced Decision Systems Internet: ·····@chesapeake.ads.com
2111 Wilson Blvd #800
Arlington, VA 22201 (703) 875-0327
In article <···················@pecos.ads.com> ·····@pecos.ads.com (Clinton Hyde) writes:
From: ·····@pecos.ads.com (Clinton Hyde)
anyway, I would like to know how (if it's possible) to find out
programmatically (or is that automagically) what condition is
signalled when some piece of code does so.
You could try wrapping the following around the offending code
(represented here is "(/ 3 0)").
(handler-case (/ 3 0)
(error (e) (format t "~&The condition ~S was signalled" e)))
In article <··················@oakland-hills.lucid.com> ····@Lucid.COM writes:
>(handler-case (/ 3 0)
> (error (e) (format t "~&The condition ~S was signalled" e)))
Be careful how you use this information. The condition type that's
signalled is often more specific than the type you want to set a handler
for. For instance, on Lisp Machines many of the error types have a subtype
that's used when the condition is signalled by a hardware trap, but when
you're writing a handler you don't usually care whether it's signalled by
hardware or software. Once you find out the condition type that's
signalled you'll probably want to use a class browser or something like it
to see the superclass hierarchy, to decide which class you should handle.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <···················@pecos.ads.com> ·····@pecos.ads.com (Clinton Hyde) writes:
>at the moment, I'm getting a ABORT or some sort signalled out of
>CLIM's accepting-values, but if I use handler-case to try to grab it,
>I seem to have the wrong name or something. so what I need today is to
>know what gets signalled when I click on the <abort> exit-box. for the
>future I'd like to know how to find ANYTHING that's signalled.
If it's done correctly, aborting should be implemented by invoking a
restart, not by signalling a condition. If you want to establish a handler
for this, you can use WITH-SIMPLE-RESTART or RESTART-CASE, specifying the
restart named ABORT.
You'll have to do this inside the ACCEPTING-VALUES, since ACCEPTING-VALUES
presumably sets up its own ABORT restart, and the innermost one is the one
that will be invoked.
It's also possible that ACCEPTING-VALUES is using some other mechanism to
implement the exit boxes. It could just be doing a RETURN-FROM.
I don't know of a way to find out what restarts or other exit mechanisms
are being invoked, the way you can for conditions being signalled. And if
it's using a lexical mechanism like GO or RETURN-FROM, there's no way for
you to intercept it even if you do find out.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar