[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dispatching on keywords
- To: firstname.lastname@example.org
- Subject: dispatching on keywords
- From: email@example.com
- Date: Tue, 17 Nov 92 16:56:32 -0500
- Cc: firstname.lastname@example.org, email@example.com, ranson@LANNION.cnet.fr
- Cc: firstname.lastname@example.org
- In-reply-to: Msg of Tue, 17 Nov 92 09:17:47 PST from email@example.com (Scot Dyer)
Date: Tue, 17 Nov 92 09:17:47 PST
From: firstname.lastname@example.org (Scot Dyer)
/// I'm not sure error values are such a good idea, even in a functional
/// language. Expanding on your example, consider:
/// (read (open-file ...
/// With error values, read can get a stream argument or an error value,
/// and so must check at run time. With non-local exits and conditions,
/// you can assert that open-file returns a stream, and the compiler will
/// optimize type checking. Or alternatively, you can write your own
/// open-file-or-return-error-value, which makes conditions more powerful
/// than error values.
It is correct that un-anticipated exception values will 'cascade'
in this kind of a scheme. This is handy in that it produces a
back-trace which it is simple to build a browser to view.
It is _not_ handy in that it produces something that could be _mistaken_
for a backtrace. Why throw away the stack in order to generate something
that looks like the stack but from which you can't continue?
/// Another common argument against error values is that usually, you don't
/// know locally what to do about the error. You miss the larger picture,
/// and it's better to exit to a higher-level function that will have a
/// better idea about what to do.
This is a good argument. Sometimes one wants errors handled transparently,
I'll admit to that, but having that be the _only_ way can make life harder
when you just want to define a simple function like
(define-method file-exists? (file-name)
(not (error? (open-file file-name))))
This is a situation where the context of an error happens to be
unimportant. I don't think it justifies throwing away potentially relevant
information (i.e. pop the stack) by default, for errors you weren't
expecting -- errors for which any relevant information may be crucial. It
_should_ take a few more keystrokes to abandon the error context in this
Matt Birkholz Cambridge Research Lab
email@example.com <DARWIN>< Digital Equipment Corp.