Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!newsfeed.internetmci.com!howland.reston.ans.net!math.ohio-state.edu!newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Wed, 27 Mar 1996 21:11:17 GMT
Message-ID: <1996Mar27.211117.5569@schbbs.mot.com>
References: <4j954n$mrq@kai.com>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 70
Xref: news.daimi.aau.dk comp.object:53301 comp.lang.eiffel:22538 comp.lang.c++:175321 comp.lang.beta:10687 comp.lang.java:29059 comp.lang.sather:12367

In article <4j954n$mrq@kai.com> robison@kai.com (Arch Robison) writes:
> I think that you missed the point of Bjarne Stroustrup's post.
> It is easy to think of examples supporting any language feature.
> The point is that people actually programming with real languages
> on real projects found that resumption semantics were inferior
> to termination semantics.
>

Note that resumption is not simply going back to the place where the
exception is raised, rather, it is a retry from the original starting
point. I don't see any inferior with this resumption semantics, which
is broardly accepted in alomost all OO languages that offer exception
handling.
 
> Stroustrup was kind enough not to post his whole Design and Evolution (D&E)
> book.  Go read it.  Section 16.6 says more than the post.  Section 16.6.1 
> explains how to get most of the benefits of resumption semantics with C++.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

If resumption semantics were inferior, why should we bother to get
its "benefits" by simulating its semantics as below:

> This is an unfair comparison, since the latter example code uses C++ features
> badly.  It's wordiness is more an artifact of the switch syntax than
> exception semantics.  I offer the following pseudocode as an improved 
> version.  It presumes that unusual conditions throw an exception, so it
> does not make calls to the hypothetical "check_error_message".
> 
>     bool retry;
>     do {
> 	retry = false;
> 	try {
> 	    result = do_something();
> 	}
> 	catch( condition1 ) {some_extraordinary_work1();  retry=true;}
> 	catch( condition2 ) {some_extraordinary_work2();  retry=true;}
> 	catch( condition3 ) {some_extraordinary_work3();  retry=true;}
>         catch( condition4 ) {result=NULL;}
>     } while( retry );
> 

How do you define these conditions? They must be in different types,
I assume, otherwise C++ cannot locate the cather.

What happen if we forget to inialize "retry"? Okay, we can use break, but
what happen if we have nested exceptions? "Goto" must be used, I guess.
Busy jumps around are no fun.

What happen if we forget to set "result" to NULL under condition4?
In code:
 
result	= try do_something()
	  {
		when condition1: some_extraordinary_work1; retry;
		when condition2: some_extraordinary_work2; retry;
		when condition3: some_extraordinary_work3; retry;
		when condition4: return null;
	  }

"return" is a must.

What happen if the exception is thrown and the caller does not provide any
catcher? Either crash the system or leave the invlid result alone?

In Transframe, "try" is a must, if "do_something" declares exceptions that
must have caller's involvement.  

David Shang