I was wondering if it could be accepted as "good style" to define a
function in a way that makes the caller able to decide whether, if an
error happens during its evaluation, the function should throw an error,
or produce a default result.
For example, an imaginary function that adds an edge between two
vertices of a graph could, depending on the value of a keyword parameter
NO-ERRORS, either throw an error if one of the vertices doesn't exist,
or silently add the missing vertices:
(defun add-edge (graph source dest &key (no-errors nil))
...)
This way, the caller could decide either to be responsible for all the
error handling (which could require a good knowledge of the underlying
mechanisms), or to let the function maintain the integrity of the data
involved (but that might not be always possible or desirable).
Any thougths? Are there any commonly accepted idioms about that issue?
Thanks,
--Matthieu
Matthieu Villeneuve <···················@tumbleweed.com> writes:
> I was wondering if it could be accepted as "good style" to define a
> function in a way that makes the caller able to decide whether, if an
> error happens during its evaluation, the function should throw an error,
> or produce a default result.
Sure, see READ as an example of that.
> For example, an imaginary function that adds an edge between two
> vertices of a graph could, depending on the value of a keyword parameter
> NO-ERRORS, either throw an error if one of the vertices doesn't exist,
> or silently add the missing vertices:
>
> (defun add-edge (graph source dest &key (no-errors nil))
> ...)
I'd call the keyword arg ERROR-P to avoid the weird double-negative.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Matthieu Villeneuve <···················@tumbleweed.com> writes:
>
> > I was wondering if it could be accepted as "good style" to define a
> > function in a way that makes the caller able to decide whether, if an
> > error happens during its evaluation, the function should throw an error,
> > or produce a default result.
>
> Sure, see READ as an example of that.
And see also my paper
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
for some conceptual foundation in this area.
> > For example, an imaginary function that adds an edge between two
> > vertices of a graph could, depending on the value of a keyword parameter
> > NO-ERRORS, either throw an error if one of the vertices doesn't exist,
> > or silently add the missing vertices:
> >
> > (defun add-edge (graph source dest &key (no-errors nil))
> > ...)
>
> I'd call the keyword arg ERROR-P to avoid the weird double-negative.
Some call it ERRORP heh.
Kent M Pitman <······@world.std.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Matthieu Villeneuve <···················@tumbleweed.com> writes:
>
> > > (defun add-edge (graph source dest &key (no-errors nil))
> > > ...)
> >
> > I'd call the keyword arg ERROR-P to avoid the weird double-negative.
>
> Some call it ERRORP heh.
Yeah ... I was actually lying, *I* would call it ERROR?, which
probably contributes to the difficulty I have reading things like
ERRORP (which my brain unfortunatey parses as ER RORP)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@apocalypse.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>
>> > Matthieu Villeneuve <···················@tumbleweed.com> writes:
>>
>> > > (defun add-edge (graph source dest &key (no-errors nil))
>> > > ...)
>> >
>> > I'd call the keyword arg ERROR-P to avoid the weird double-negative.
>>
>> Some call it ERRORP heh.
>
>Yeah ... I was actually lying, *I* would call it ERROR?, which
>probably contributes to the difficulty I have reading things like
>ERRORP (which my brain unfortunatey parses as ER RORP)
As you program in Common Lisp some more, you'll probably get used to
parsing XXXP as XXX-P and interpreting -P as '?'.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote:
> >Kent M Pitman <······@world.std.com> writes:
> >
> >> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >>
> >> > Matthieu Villeneuve <···················@tumbleweed.com> writes:
> >>
> >> > > (defun add-edge (graph source dest &key (no-errors nil))
> >> > > ...)
> >> >
> >> > I'd call the keyword arg ERROR-P to avoid the weird double-negative.
> >>
> >> Some call it ERRORP heh.
> >
> >Yeah ... I was actually lying, *I* would call it ERROR?, which
> >probably contributes to the difficulty I have reading things like
> >ERRORP (which my brain unfortunatey parses as ER RORP)
>
> As you program in Common Lisp some more, you'll probably get used to
> parsing XXXP as XXX-P and interpreting -P as '?'.
Well, two and a half years so far, and no sign of my reading errorp
any better, yet. I have no problem with -P, just with the no-hyphen
version. In my own code, I'm quite consistent: ERROR? and READ-ERROR?
(signal an error on read?), but READER-ERROR-P (is this a reader-error?).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <·················@tumbleweed.com>,
Matthieu Villeneuve <···················@tumbleweed.com> wrote:
>I was wondering if it could be accepted as "good style" to define a
>function in a way that makes the caller able to decide whether, if an
>error happens during its evaluation, the function should throw an error,
>or produce a default result.
...
>Any thougths? Are there any commonly accepted idioms about that issue?
>Thanks,
Take a look at most of the standard input functions, which take EOF-ERROR-P
and EOF-VALUE arguments.
However, in many cases, the caller can simply use IGNORE-ERRORS when he's
not interested in the error details.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Erik Naggum
Subject: Re: Function design: make errors optional?
Date:
Message-ID: <3225695040075213@naggum.net>
* Matthieu Villeneuve
| I was wondering if it could be accepted as "good style" to define a
| function in a way that makes the caller able to decide whether, if an
| error happens during its evaluation, the function should throw an error,
| or produce a default result.
You might find warn and signal useful in this regard, instead of error.
That way, your caller may set up a condition handler and decline to
handle a particular condition, or not set up any condition handlers and
effectively ignore the conditions, such that you can return a useful
default value instead.
| For example, an imaginary function that adds an edge between two
| vertices of a graph could, depending on the value of a keyword parameter
| NO-ERRORS, either throw an error if one of the vertices doesn't exist,
| or silently add the missing vertices:
I think a keyword argument like :if-does-not-exist with a :create or
:error argument would be a good design choice here. See open.
| Any thougths? Are there any commonly accepted idioms about that issue?
Well, there are several. read has already been mentioned.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.