From ... Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!sunqbc.risq.qc.ca!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.functional,comp.lang.dylan Subject: Re: New Lisp ? References: Mail-Copies-To: never From: Erik Naggum Message-ID: <3219064864562397@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 16:41:08 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader3.kpnqwest.net 1010076068 193.71.66.49 (Thu, 03 Jan 2002 17:41:08 MET) NNTP-Posting-Date: Thu, 03 Jan 2002 17:41:08 MET Xref: archiver1.google.com comp.lang.scheme:8010 comp.lang.lisp:23560 comp.lang.functional:9521 comp.lang.dylan:1591 * 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. /// --