Hello,
I'm going to rewrite and secure a big Lisp program, and wish to inject
some code for EXCEPTION HANDLING.
The Lisp dialect I use (Le-Lisp developped by ILOG, a french company)
has no notion about exception and I'll be obliged to use (and may be
developp) a separate functions package.
Have you ever heard about such package available in the net ?
What about your experience in this 'exceptionnal sport' :-) ?
How do you handle exceptions (and errors) in your Lisp functions ?
In an article of this group (about EuLisp) I read that some modern Lisp
dialects had exception handling features:
- how does it work ?
- is-it efficient ?
Thanks (and sorry for my bad accent (and a lot of mistakes))
Jerome.
--
Jerome BOULENGER | LGI - IMAG
projet SHERPA / SHOOD | GRENOBLE, FRANCE
E-mail: ················@imag.fr | Tel: 76.51.46.00 Poste 33.42
In article <··········@imag.fr> ·······@imag.fr (Jerome Boulenger) writes:
>Hello,
>
>I'm going to rewrite and secure a big Lisp program, and wish to inject
>some code for EXCEPTION HANDLING.
>
>The Lisp dialect I use (Le-Lisp developped by ILOG, a french company)
>has no notion about exception and I'll be obliged to use (and may be
>developp) a separate functions package.
Are you sure? I'm pretty sure that at least recent versions of
Le Lisp have exception handling.
Sorry it took so long to answer; our news server died for a couple
days.
In article <··········@imag.fr> ·······@imag.fr (Jerome Boulenger) writes:
Hello,
I'm going to rewrite and secure a big Lisp program, and wish to inject
some code for EXCEPTION HANDLING.
The Lisp dialect I use (Le-Lisp developped by ILOG, a french company)
has no notion about exception and I'll be obliged to use (and may be
developp) a separate functions package.
Le-Lisp v. 15 actually does has an exception mechanism. Check out the
ITSOFT set of functions in chapter 7 of the 15.25 reference manual.
In an article of this group (about EuLisp) I read that some modern Lisp
dialects had exception handling features:
- how does it work ?
- is-it efficient ?
EuLisp has a simple but powerful condition system based on condition
objects and generic function handlers. Ilog Talk, our next generation
Lisp product, uses the EuLisp condition system. (For more information
about Ilog Talk, you should contact ····@ilog.fr. IMAG is a beta
tester for Ilog Talk - please talk to Francois Rechenmann if you want
to use it there.)
As far as efficiency goes, it is generally considered important that
the establishment of a handler be efficient to encourage trapping
errors, while signaling a condition may be somewhat more inefficient,
since in principle it happens only rarely. In Ilog Talk 3.0,
establishing a handler pushes a Lisp stack frame and an allocation of
a cons cell, while signaling a condition needs to go through the stack
of handlers, determining the first which is applicable for the
condition object. This uses the generic function dispatch mechanism
which costs approximately 5x a normal function call. So the cost of
signaling is basically 5 x handler stack depth to first handler x
function call cost (= C function call in Ilog Talk).
I hope this answers your question.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
Harley Davis <·····@ilog.fr> wrote:
>
>As far as efficiency goes, it is generally considered important that
>the establishment of a handler be efficient to encourage trapping
>errors, while signaling a condition may be somewhat more inefficient,
>since in principle it happens only rarely. In Ilog Talk 3.0,
>establishing a handler pushes a Lisp stack frame and an allocation of
>a cons cell, while signaling a condition needs to go through the stack
>of handlers, determining the first which is applicable for the
>condition object.
In comp.compilers a few weeks back, David Chase wrote a long
description of exception handling support in a Sun C++ compiler.
Essentially, the compiler records the program counter range of
instructions a handler covers. This information as well as info about
how to test and invoke the handler is made available at run time. On
signalling, the saved PC for each stack frame is examined, and, if it
falls within a handler's range, the run time system uses the recorded
info to test against the condition object and invoke the handler if
necessary. (Mind you, this is much easier said than done.) So,
establishing a handler costs nothing, and signalling costs little more
than the usual CL implementation strategy. A good trade-off, and a
cool trick.
--David Gadbois