I am a student of Java, my teacher has asked me to compare Java and
Lisp. I have been reading about Lisp error signaling in the Ansi
Hyperspec and Steele manual about common Lisp. My question is this:
In my reading it seems that signalling an error and throwing an
exception are pretty much the same thing. Steele states that it is
implementation dependent on how the error is signalled, but from my
reading it looks as if though it is implied that they are pretty
similar. However, does an error being signaled always result in the
Lisp debugger being activated? Well, I hope its a fairly simple
question. :)
Thanks in advance,
Feral
Feral Dragoon <·····@dragoon.net> writes:
> I am a student of Java, my teacher has asked me to compare Java and
> Lisp. I have been reading about Lisp error signaling in the Ansi
> Hyperspec and Steele manual about common Lisp. My question is this:
> In my reading it seems that signalling an error and throwing an
> exception are pretty much the same thing. Steele states that it is
> implementation dependent on how the error is signalled, but from my
> reading it looks as if though it is implied that they are pretty
> similar. However, does an error being signaled always result in the
> Lisp debugger being activated? Well, I hope its a fairly simple
> question. :)
In Lisp, exceptions aren't thrown, they're raised. The difference is
that the stack isn't unwound first[*]. So, whatever code (the
debugger, user code, whatever) handles the exception, can do so in the
dynamic environment that the exception occured in. That includes the
ability to fix the problem, and continue as if nothing went wrong.
Throwing up the stack is generally used as just a control-flow
mechanism.
The difference between these two is *huge*. If it doesn't seem like
it, try to get used to thinking about handling errors in the dynamic
context in which they occured. Then look at some programs you have,
and think of how you could have done things differently. That one
linguistic change would make my Java programs simpler, smaller, and
probably more robust. There are other things in Lisp that I
understand why they didn't make it to Java. This, I don't.
[*] There are two ways of establishing exception handlers. You can
have your code handle the exception without any stack unwinding, or
you can have the stack unwound first. The second case is, of course,
just a special case of the first.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Feral Dragoon <·····@dragoon.net> writes:
> I am a student of Java, my teacher has asked me to compare Java and
> Lisp. [...] However, does an error being signaled always result in
> the Lisp debugger being activated? Well, I hope its a fairly simple
> question. :)
No:
(handler-case (error "There was an error! :(")
(error ()
(princ "We signalled an error and didn't enter the debugger!")))
If you really want to look at something different between the Lisp
and Java exception systems, take a look at restarts and handlers
in Lisp...
Gabe Garza
Feral Dragoon <·····@dragoon.net> writes:
> I am a student of Java, my teacher has asked me to compare Java and
> Lisp. I have been reading about Lisp error signaling in the Ansi
> Hyperspec and Steele manual about common Lisp. My question is this:
> In my reading it seems that signalling an error and throwing an
> exception are pretty much the same thing.
They are.
> Steele states that it is
> implementation dependent on how the error is signalled, but from my
> reading it looks as if though it is implied that they are pretty
> similar. However, does an error being signaled always result in the
> Lisp debugger being activated? Well, I hope its a fairly simple
> question. :)
AFAIK, that is really implementation dependent. As a matter of fact I
just had a discussion with a student who was modifying my code and was
lauching several Lisp images from a shell script (who said that CL has
slow startup times :) ? ). He was complaining because the each Lisp
would get into the debugger instead of exiting like you "standard"
P..... program. After a few back and forth understanding exactly what
he was trying to do we simply ended up doing
(defun the-main-function ()
(handler-case (stuff)
(error (e)
(quit))))
simple and perfect.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Feral Dragoon <·····@dragoon.net> writes:
>
> > I am a student of Java, my teacher has asked me to compare Java and
> > Lisp. I have been reading about Lisp error signaling in the Ansi
> > Hyperspec and Steele manual about common Lisp. My question is this:
> > In my reading it seems that signalling an error and throwing an
> > exception are pretty much the same thing.
>
> They are.
No, as Thomas F. Burdick has already explained in good detail, signaling
does not imply unwinding the stack. Signaling merely creates the option
of doing so. It is part of the handling process that the stack gets unwound.
If you use HANDLER-CASE, you'll get a behavior that's very Java-like
(the clauses are executed AFTER unwind), but if you use HANDLER-BIND,
you'll be handling the error BEFORE unwind, which Java has no way to do.
See Thomas's longer answer or my paper
http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
for more detail.
> > Steele states that it is
> > implementation dependent on how the error is signalled, but from my
> > reading it looks as if though it is implied that they are pretty
> > similar. However, does an error being signaled always result in the
> > Lisp debugger being activated? Well, I hope its a fairly simple
> > question. :)
>
> AFAIK, that is really implementation dependent. As a matter of fact I
> just had a discussion with a student who was modifying my code and was
> lauching several Lisp images from a shell script (who said that CL has
> slow startup times :) ? ). He was complaining because the each Lisp
> would get into the debugger instead of exiting like you "standard"
> P..... program. After a few back and forth understanding exactly what
> he was trying to do we simply ended up doing
>
> (defun the-main-function ()
> (handler-case (stuff)
> (error (e)
> (quit))))
>
> simple and perfect.
This is mostly fine for as far as it goes. Essentially, the user is
asking to have the Java-like, unhelpful behavior.
Another way to get similar effect is:
(defun the-main-function ()
(let ((*debugger-hook* #'(lambda (&rest who-cares)
(declare (ignore who-cares))
(quit))))
(stuff)))
In this way, you won't shadow an outer handler around (the-main-function)
and yet you still won't enter the debugger ultimately.
But this all misses the point. If you don't like the debugger, try
doing THIS in Java:
(defun the-main-function ()
(flet ((handle-randomly (condition)
(invoke-restart-interactively
(let ((restarts (compute-restarts condition)))
(nth (random (length restarts)) restarts)))))
(handler-bind ((error #'handle-randomly))
(stuff))))
[I didn't test this. Left as an exercise to the reader.]
This ALSO does not enter the debugger but it does something much more
novel than Java is able to do.
The right way to think of the debugger, by the way, is as the
"interactive handler". It gets control before the stack unwinds, just
as a program handler would, it is just the program handler of last resort.
It typically calls COMPUTE-RESTARTS to find out what options there are
for continuing and it typically asks the user which restart to use,
typically allowing the user to poke at the machine state in some
implementation-dependent way. You can write your own debugger that is
friendlier, though, if you like. You can make it just pop up an icon
of a bomb and say the error message and wait for you to click "OK" before
doing the first of the computed restarts if you like. Lots of things
can count as the debugger...
The debugger, by being interactive, is intended to work with you to develop
a theory of how to do the handling so that when you get bored by doing
the same thing over and over to proceed you eventually can write a handler
that does that action. In that way, things become more automated over time
as you learn more about how regular the situation surrounding the error
is and whether there are sometimes alternate recovery strategies you need,
etc.
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Feral Dragoon <·····@dragoon.net> writes:
> >
> > > I am a student of Java, my teacher has asked me to compare Java and
> > > Lisp. I have been reading about Lisp error signaling in the Ansi
> > > Hyperspec and Steele manual about common Lisp. My question is this:
> > > In my reading it seems that signalling an error and throwing an
> > > exception are pretty much the same thing.
> >
> > They are.
>
> No,
Well, I guess I just fell for the "simple, easy, and wrong" :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kent M Pitman <······@world.std.com> writes:
> The right way to think of the debugger, by the way, is as the
> "interactive handler". It gets control before the stack unwinds, just
> as a program handler would, it is just the program handler of last resort.
> It typically calls COMPUTE-RESTARTS to find out what options there are
> for continuing and it typically asks the user which restart to use,
> typically allowing the user to poke at the machine state in some
> implementation-dependent way. You can write your own debugger that is
> friendlier, though, if you like. You can make it just pop up an icon
> of a bomb and say the error message and wait for you to click "OK" before
> doing the first of the computed restarts if you like. Lots of things
> can count as the debugger...
>
> The debugger, by being interactive, is intended to work with you to develop
> a theory of how to do the handling so that when you get bored by doing
> the same thing over and over to proceed you eventually can write a handler
> that does that action. In that way, things become more automated over time
> as you learn more about how regular the situation surrounding the error
> is and whether there are sometimes alternate recovery strategies you need,
> etc.
Thanks for this !
(Any sign on the horizon of the Lisp book you mentioned you might be
writing? which I suspect might contain much condition handling
wisdom.)
Feral Dragoon wrote:
> I am a student of Java, my teacher has asked me to compare Java and
> Lisp. I have been reading about Lisp error signaling in the Ansi
> Hyperspec and Steele manual about common Lisp. My question is this:
> In my reading it seems that signalling an error and throwing an
> exception are pretty much the same thing. Steele states that it is
> implementation dependent on how the error is signalled, but from my
> reading it looks as if though it is implied that they are pretty
> similar. However, does an error being signaled always result in the
> Lisp debugger being activated? Well, I hope its a fairly simple
> question. :)
You can find an excellent overview of exception handling in Lisp at
http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
(I have also only recently made the step from Java to Lisp, and that
paper helped me a lot to understand the differences.)
All the best,
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Wed, 27 Nov 2002 04:45:07 GMT, Feral Dragoon <·····@dragoon.net> wrote:
> I am a student of Java, my teacher has asked me to compare Java and
> Lisp. I have been reading about Lisp error signaling in the Ansi
> Hyperspec and Steele manual about common Lisp. My question is this:
Here are a couple more resources:
Condition Handling in the Lisp Language Family
http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
Exceptional Situations In Lisp
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README