[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Lisp ?
- To: address@hidden
- Subject: Re: New Lisp ?
- From: David Rush <address@hidden>
- Date: Wed, 2 Jan 2002 06:45:01 -0500 (EST)
- Organization: Netscape Communications Corporation
- References: <c571739c.0112211614.24569c07@posting.google.com> <okfg064ugsh.fsf@bellsouth.net> <3218011993496537@naggum.net> <okf4rmjv2n6.fsf@bellsouth.net> <3218025363470352@naggum.net> <slrna2acon.8d1.markj+0111@cloaked.freeserve.co.uk> <c571739c.0112222317.3d2be7fd@posting.google.com> <slrna2b8q0.1bm.markj+0111@cloaked.freeserve.co.uk> <c571739c.0112230535.2dd6f1b1@posting.google.com> <scoc2u4qkpue4mt9irr0cldu5ig913qogr@4ax.com> <l91d2ucqplfm9auo2gi20pd74ktnl2utlp@4ax.com> <ni8f2uck3ua78ucps9kg9c4sal2g38r85v@4ax.com> <87vgew4631.fsf@teonanacatl.andreas.org> <3C27C7BC.DECCE7DB@quiotix.com> <87pu542jjz.fsf@teonanacatl.andreas.org> <3C27D85C.9E5FE363@quiotix.com> <87ellk9el3.fsf@teonanacatl.andreas.org> <3C28500F.6652B4EB@quiotix.com> <874rmf3x4c.fsf@teonanacatl.andreas.org> <okfsn9xs9do.fsf@bellsouth.net> <877kr9l24k.fsf@teonanacatl.andreas.org> <3C2AB04C.F4586FA8@quiotix.com> <87pu51jjx4.fsf@teonanacatl.andreas.org>
- User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands)
- Xref: traf.lcs.mit.edu comp.lang.scheme:38504 comp.lang.lisp:78577 comp.lang.functional:29741 comp.lang.dylan:13911
Andreas Bogk <andreas@andreas.org> writes:
> Jeffrey Siegal <jbs@quiotix.com> writes:
>
> > What happens in Java is that you have to at least declare the exceptions
> > up the chain anyway (the compiler will reject a method that doesn't
>
> Yes, and that bothers me to no end. I want to have specific code that
> knows about an exception in exactly two places: where it is generated,
> and where it can be handled. All the code inbetween doesn't need to
> know more than that an operation has failed and that it needs to clean
> up.
Well the `two endpoints' part of your desire is fairly easily met, but
the `cleaning up from the middle' is rather harder. I would speculate
that the only way to make that really work correctly is to have
language (& GC) support for finalizers, and even that is error prone.
In my experience, error-handling has to be designed in early. My
experience with exception-based systems (primarily Smalltalk w/some
C++) has not led me to believe that they are dramatically
cleaner.
Please note: I am talking about a matter of degree here. My biggest
beef with exception-based systems is that they end up getting used far
too generally (for unusual code paths rather than actual failure
handling). They're nice when used for communicating distant problems
(the canonical I/O system failure is ideal), but they're not as clear
as an if statement by any means. In the past I've dealt with this
through architectural constraints, but that experience was not wholly
satisfying.
david rush
--
Christianity has not been tried and found wanting; it has been found
difficult and not tried.
-- G.K. Chesterton