[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Lisp ?
- To: address@hidden
- Subject: Re: New Lisp ?
- From: Erik Naggum <address@hidden>
- Date: Thu, 3 Jan 2002 11:45:01 -0500 (EST)
- Mail-copies-to: never
- Organization: Naggum Software, Oslo, Norway
- References: <c571739c.0112211614.24569c07@posting.google.com> <l91d2ucqplfm9auo2gi20pd74ktnl2utlp@4ax.com> <ni8f2uck3ua78ucps9kg9c4sal2g38r85v@4ax.com <okfpu4tq8z7.fsf@bellsouth.net> <a10hpp$jel7$1@fido.engr.sgi.com>
- User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
- Xref: traf.lcs.mit.edu comp.lang.scheme:38530 comp.lang.lisp:78655 comp.lang.functional:29760 comp.lang.dylan:13921
* Rob Warnock
| In particular, allowing some [presumably infrequent] non-error code
| paths to be considered "exceptional" [and using inconspicuous flow
| control primitives to access them, such as CATCH/THROW] can, in turn,
| allow the "normal" code paths to be considerably simplified without
| compromising program correctness.
I have always thought of "exceptions" to refer to exceptions from the
expected control flow. That is, if I am prepared to handle something, it
obviously goes in the normal control flow, but if I have no idea what do
with a particular situation that I know could arise, use an exception.
E.g., in a low-level I/O function, reaching the end of file or a full
disk or whatever is to be expected, but code that reads or writes known
objects from or to a stream should not have to expect such things and
should be able to throw up it hands and ask an exception handler to take
over, perhaps recovering and continuing.
///
--