Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!goldenapple.srv.cs.cmu.edu!das-news2.harvard.edu!news.dfci.harvard.edu!camelot.ccs.neu.edu!news.mathworks.com!news-peer.sprintlink.net!news.sprintlink.net!sprint!ix.netcom.com!nagle
From: nagle@netcom.com (John Nagle)
Subject: Re: Java vs lisp (was: Re: Prolog vs. Lisp)
Message-ID: <nagleE8Fq0D.Mvx@netcom.com>
Organization: Netcom On-Line Services
X-Newsreader: NN version 6.5.0 CURRENT #9
References: <3340DFEC.3C0F@netvision.net.il> <3341B6DE.6970@felix.cc.gatech.edu> <nagleE7zr39.CF1@netcom.com> <3365440d.698147468@newshost> <5huud5$fkt@mulga.cs.mu.OZ.AU> <33749971.785543968@newshost> <33444A61.A85E0D6@tkg.com>
Date: Thu, 10 Apr 1997 18:29:01 GMT
Lines: 24
Sender: nagle@netcom6.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.ai:45440 comp.lang.java.advocacy:8060 comp.lang.lisp:26627

Rob Mayoff <mayoff@tkg.com> writes:
>Jason Trenouth wrote:
>> The language. I believe (correct me if I'm mistaken) that in Java, the stack
>> is unwound _before_ a handler runs. This makes some kinds of recovery much
>> clumsier than in Common Lisp, where the handler can run with all the context
>> of the signaller.
>Yes, for exception handlers Java has termination semantics, not
>resumption semantics. See "The Design and Evolution of C++" (by Bjarne
>Stroustrup), section 16.6.  He discusses at length why they choose
>termination semantics for C++ (and the reasons given include significant
>real-world experience with both kinds of semantics).  All the same
>arguments apply for Java.

     LISP has much cleaner break semantics than C++, and especially
Java, so it is possible to do recovery.   But except for debugging,
it's probably not a good idea.  

     At the other extreme, there's Ada.  Ada introduced exceptions
with termination semantics, and Ada needs to work that way; it
supports exceptions for hardware errors, like memory parity.
Ada is used for embedded applications like aircraft control systems, 
where recovery is essential.

					John Nagle
