Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!mn6.swip.net!plug.news.pipex.net!pipex!tube.news.pipex.net!pipex!dish.news.pipex.net!pipex!bt!btnet!newsfeed.internetmci.com!csn!news-1.csn.net!decwrl!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!news.salford.ac.uk!aber!not-for-mail From: pcg@aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather Subject: Re: What Should An Exception Handling Do? -- Clarification of rules Date: 05 Apr 1996 17:38:52 +0100 Organization: Prifysgol Cymru, Aberystwyth Lines: 107 Sender: pcg@osfb.aber.ac.uk Message-ID: References: <1996Apr2.154722.29777@schbbs.mot.com> Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) NNTP-Posting-Host: osfb.aber.ac.uk In-reply-to: shang@corp.mot.com's message of Tue, 2 Apr 1996 15:47:22 GMT X-Newsreader: Gnus v5.0.15 Xref: news.daimi.aau.dk comp.object:53850 comp.lang.eiffel:22688 comp.lang.c++:177051 comp.lang.beta:10710 comp.lang.java:31923 comp.lang.sather:12421 >>> On Tue, 2 Apr 1996 15:47:22 GMT, shang@corp.mot.com (David L. Shang) >>> said: shang> In article pcg@aber.ac.uk shang> (Piercarlo Grandi) writes: pcg> Therefore exception handling reduces to simply providing a mechanism by pcg> which the *author* of a code segment provides a mechanism by which the pcg> *user* of that code segment can specify additional cases, as for example pcg> in: pcg> float sqrt(float n) pcg> { pcg> if pcg> n > 0 -> ...; pcg> [] n == 0 -> return 0; pcg> [] n < 0 -> return sqrt_negative(n); pcg> fi pcg> } pcg> where the only difficulty is that sqrt_negative must be dynamically pcg> scoped instead of statically scoped, for it must be redefinable by pcg> the *user* of the procedure. pcg> This again means that termination is the only possible outcome for pcg> this case too. shang> Termination? When you execute: shang> return sqrt_negative(n) shang> first, you call "sqrt_negative" to get the result, then you do shang> return to terminate. It is not the case that you first terminate shang> then you call "sqrt_negative".shang> go back. This is just a low level, mechanical view of exceptions/termination/resumption, as indeed demonstrated by your subsequent example, which is nothing but an assembler-like expansion of what I had written above: shang> Once your terminate, you can never If I write code like: shang> float sqrt(float n) shang> { shang> if shang> n > 0 -> ...; shang> [] n == 0 -> return 0; shang> [] n < 0 -> { n1= sqrt_negative(n); return n1; } shang> fi shang> } shang> Is the program terminated Why should one terminate the _program_? Exception handling's purpose is precisely not to terminate the program, but to allow it to continue, even if on a different path. When we are talking of termination/continuation semantics, we are talking about the termination/continuation of the bit of code that had the problem, not that of the program (or even that of the containing scope, I would say). shang> at the point of calling "sqrt_negative"? This embedded exception shang> handler exactly provides a resumption semantics, Not at all: for the 'if-fi' is not resumed/continued in any way. Actually if you agree, as you logically must, that an "exception" is a misnomer for the case where a partial function is applied to a value outside its codomain, then talking about "exception handlers" and termination and continuation does not mean much: the only thing that matter is that the partial function is not continued, and that another bit of code is used. The advocates of continuation semantics think that it makes sense because they imagine it is possible to make the exception handler wiggle things so that the current state of the computation is changed to one that *is* in codomain of the ``failing'' partial function; for example if on reading one gets EOF on the current volume, the exception handler can mount another volume, and on resumption the EOF is gone and everything is OK. But I'd regard this a terrible use of "exception handling", for there is no need to use the machinery of dynamic binding in this case, because what happens on EOF is not something that cannot be designed in at the time the rest of the code is written; in fact essentially all the uses of continuation sematics amount to using exception handling instead of a 'case' or an 'if' with more branches. shang> which, according to your previous analysis, is the only case that shang> exception handling makes any sense(?). Perhaps we are using "termination" in a different sense: to me in a semantic sense, where the current computation simply cannot progress because it is a partial function applied to a value outside its codomain. If a partial function is applied outside its codomain, then it simply *cannot* be continued/resumed/... You are instead perhaps thinking of non-local control transfers, as in: termination semantics for exceptions *necessarily* involve a non local control transfer. To me the issue of exception handling and non local control transfers are totally unrelated and independent; not necessarily an exception handler shall 'longjmp'/'throw'/... outside the current function. What in any case *must* happen is that the current computation is not continued, for it cannot continue.