From: Peter Seibel
Subject: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <m3wu1ve2h7.fsf@javamonkey.com>
This week's topic: conditions and restarts. Read all about it here:
<http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html>
and send me your comments, suggestions, and flames.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> This week's topic: conditions and restarts. Read all about it here:
>
> <http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html>
>
> and send me your comments, suggestions, and flames.
>
> -Peter
Peter,
That's the best explanation of restarts I've ever read. And a great
real-world example too. They're so simple - but who knew?
Thanks,
Chris Perkins
Peter Seibel wrote:
> This week's topic: conditions and restarts. Read all about it here:
>
> <http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html>
>
> and send me your comments, suggestions, and flames.
>
> -Peter
>
>
Thank you for getting me started on conditions.
My comments -
1. This was something really new for me. I have read other books on Lisp
and haven't come across a chapter on conditions (not counting cltl2). I
wish this chapter had more stuff, don't know what though :)
2. You use handler-case to invoke the main code and then provide
handlers. As in
...(restart-case (parse-log-entry text)
(skip-log-entry () nil))...
In examples in "Condition Handling in the Lisp Language Family" paper by
KMP (not sure if I can post the link), he detects a situation that
requires raising of a condition and the restartable-form of restart-case
consists simply of something like (signal 'end-of-page) as in
...(restart-case (signal 'end-of-page)
(continue ()))
These look like two different styles. Have I understood this right or is
there more to this.
-Antony
From: Peter Seibel
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <m3658r8c39.fsf@javamonkey.com>
Antony Sequeira <·············@hotmail.com> writes:
> Peter Seibel wrote:
>
>> This week's topic: conditions and restarts. Read all about it here:
>>
>> <http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html>
>> and send me your comments, suggestions, and flames.
>> -Peter
>>
> Thank you for getting me started on conditions.
>
> My comments -
> 1. This was something really new for me. I have read other books on
> Lisp and haven't come across a chapter on conditions (not counting
> cltl2). I wish this chapter had more stuff, don't know what though :)
>
> 2. You use handler-case to invoke the main code and then provide
> handlers. As in
> ...(restart-case (parse-log-entry text)
> (skip-log-entry () nil))...
> In examples in "Condition Handling in the Lisp Language Family" paper
> by KMP (not sure if I can post the link), he detects a situation that
> requires raising of a condition and the restartable-form of
> restart-case consists simply of something like (signal 'end-of-page)
> as in
> ...(restart-case (signal 'end-of-page)
> (continue ()))
> These look like two different styles. Have I understood this right or
> is there more to this.
It is, I think, just a question of how far back you want to "unwind"
when the restart is invoked. In KMP's example the point is that
there's essentially nothing that needs to be undone--the condition is
signaled and the handler can do whatever and then invoke the CONTINUE
restart to continue exactly after the RESTART-CASE. In my example the
call to PARSE-LOG-ENTRY was going to do some stuff and return a value
but if it signals an error the SKIP-LOG-ENTRY restart is available to
make the RESTART-CASE as a form return NIL which the code immediately
around the RESTART-CASE is ready for.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Jacek Generowicz
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <tyf3c3tv2lw.fsf@pcepsft001.cern.ch>
Antony Sequeira <·············@hotmail.com> writes:
> 1. This was something really new for me. I have read other books on
> Lisp and haven't come across a chapter on conditions (not counting
> cltl2). I wish this chapter had more stuff, don't know what though :)
I think that this is an important observation. To my knowledge, there
are no books that _teach_ about the CL condition system. There is
CLTL, but that merely tells you what there is, it's not too hot for
showing you what the point is, and how to use it. (KMP used to mention
that he was writing a book on Lisp, and I would guess that it would
cover the condition system very well ... but I'm not holding by
breath.)
So, Peter, your book will be the only one (in the near to middle
future) teaching the condition system ... and I think that makes your
condition system chapter extremely important.
From: Barry Wilkes
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <vfgqti4o.fsf@acm.org>
Peter,
I appreciate that this is a little late, but my eye caught the unqualified
comment "While exceptions are a vast improvement over using normal function
returns..." I remembered reading an article by Joel Spolsky
(http://www.joelonsoftware.com/items/2003/10/13.html), which basically
presented a pretty good argument *against* exceptions in Java and C++. I know
that exception handling in Lisp is far more powerful than that in these
languages, but then in Lisp we also have the benefit of functions returning
multiple values, which as pointed out in the article, can be used very
effectivly for error handling.
I do think that, given that the book is introductory in nature, it probably
is worth defending your statement a bit, rather than just letting it stand.
Regards,
Barry Wilkes.
From: Jacek Generowicz
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <tyf7jt5v2vb.fsf@pcepsft001.cern.ch>
Barry Wilkes <·······@acm.org> writes:
> I remembered reading an article by Joel Spolsky
> (http://www.joelonsoftware.com/items/2003/10/13.html), which
> basically presented a pretty good argument *against* exceptions in
> Java and C++.
It seems to present a pretty good argument against Java and C++ :-)
> I know that exception handling in Lisp is far more powerful than
> that in these languages, but then in Lisp we also have the benefit
> of functions returning multiple values, which as pointed out in the
> article, can be used very effectivly for error handling.
The article _stated_ that returning multiple values can be used very
effectively for error handling. I don't think that this claim would
stand up to critical inspection in the context of writing real
programs. Do you really want to pollute each and every function with
error status checking?
Exceptions provide an orthogonal system for program flow
control. Exceptions allow you to ignore the messages that the
exceptions are conveying in all the places where those messages do not
concern you. If one fails to grasp this point, then I can see how one
could reach conclusions like Spolsky's.
> I do think that, given that the book is introductory in nature, it
> probably is worth defending your statement a bit, rather than just
> letting it stand.
... but this may well be a valid point.
From: Karl A. Krueger
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <cd64pi$6dd$1@baldur.whoi.edu>
Jacek Generowicz <················@cern.ch> wrote:
> Exceptions provide an orthogonal system for program flow
> control. Exceptions allow you to ignore the messages that the
> exceptions are conveying in all the places where those messages do not
> concern you. If one fails to grasp this point, then I can see how one
> could reach conclusions like Spolsky's.
I wonder, though, if Spolsky's concern might be better addressed as
such: The exceptions that a routine can raise form part of the API for
that routine, just as much as the routine's arguments and return value.
If you're writing routine A that uses routines B, C, and D, then you
need to either (a) handle all the exceptions that B, C, and D can raise,
or (b) document for the user of routine A which exceptions *he* is
expected to handle.
Java makes this explicit with the "throws" keyword: an exception can
only propagate up the stack through methods which have declared it as
part of their API. This seems to be the static-typing approach again:
just as a method has a return type, it has a set of exception types. So
much for static typing. :)
I have a piece of code which talks to an SQL database using CLSQL. It
does not handle every error that CLSQL can raise (chiefly because I have
not gone through the list of CLSQL errors and established what I want as
error handling for each one -- yet).
If I handed this code's API to someone else, I would need to tell them,
"By the way, this might raise exceptions of type CLSQL-SYS:SQL-ERROR.
Handle those or *your* stuff ends up in the debugger."
Of course, what seems like a nicer thing to do is establish useful
restarts for each error, and document *those* for the user. So instead
of "Handle these errors or eat debugger," my documentation says "Here
are some errors, and here are some restarts; take your pick. Even if
you *do* end up eating debugger, my code will give you useful options as
to what to do there."
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Jacek Generowicz
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <tyfzn60s3ma.fsf@pcepsft001.cern.ch>
"Karl A. Krueger" <········@example.edu> writes:
> The exceptions that a routine can raise form part of the API for
> that routine, just as much as the routine's arguments and return value.
> If you're writing routine A that uses routines B, C, and D, then you
> need to either (a) handle all the exceptions that B, C, and D can raise,
> or
Absolutely not. Some of those exceptions will, typically, not be
messages to you, but someone further down the stack. Don't mess with
ones you aren't prepared/supposed to deal with: they are none of your
business. And you certainly shouldn't be forced to notice them, and
pass them down the stack yourself.
> (b) document for the user of routine A which exceptions *he* is
> expected to handle.
This sounds fair enough ... but is a far cry from "returning multiple
values is very effective for error handling".
From: Karl A. Krueger
Subject: Re: Chapter 16 of Practical Common Lisp ready for review.
Date:
Message-ID: <cd8rfl$55m$1@baldur.whoi.edu>
Jacek Generowicz <················@cern.ch> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> The exceptions that a routine can raise form part of the API for
>> that routine, just as much as the routine's arguments and return value.
>> If you're writing routine A that uses routines B, C, and D, then you
>> need to either (a) handle all the exceptions that B, C, and D can raise,
>> or
>
> Absolutely not. Some of those exceptions will, typically, not be
> messages to you, but someone further down the stack. Don't mess with
> ones you aren't prepared/supposed to deal with: they are none of your
> business. And you certainly shouldn't be forced to notice them, and
> pass them down the stack yourself.
... that being what's strange about the Java way of doing exceptions,
yes.
Here's where I'm not so sure, though: The user of routine A might not
know how A is implemented -- that is, what underlying routines it uses.
He therefore wouldn't know to expect a B:ERROR or C:ERROR coming up from
routines B or C which are called by A, *unless* A's documentation makes
it clear that those can arise.
Or, put another way, a change in the implementation of A which does not
affect its "normal" behavior might still change its "exceptional"
behavior. If I have a data storage routine implemented with flat files
and I change it to use an SQL database via CLSQL, then suddenly my
routine becomes a potential source of CLSQL-SYS:SQL-ERROR exceptions.
The user of my routine needs to change his code to handle these instead
of handling file exceptions.
>> (b) document for the user of routine A which exceptions *he* is
>> expected to handle.
>
> This sounds fair enough ... but is a far cry from "returning multiple
> values is very effective for error handling".
Thoroughly agreed. Exceptions are the Right Thing.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews