Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!columba.udac.uu.se!news.mdh.se!news.seinf.abb.se!erinews.ericsson.se!cnn.exu.ericsson.se!newshost.convex.com!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!kai.com!not-for-mail From: robison@kai.com (Arch Robison) 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: 26 Mar 1996 10:14:15 -0600 Organization: Kuck & Associates, Inc. Lines: 85 Message-ID: <4j954n$mrq@kai.com> References: <1996Mar25.160011.13921@schbbs.mot.com> NNTP-Posting-Host: kai.com Xref: news.daimi.aau.dk comp.object:53328 comp.lang.eiffel:22546 comp.lang.c++:175409 comp.lang.beta:10689 comp.lang.java:29193 comp.lang.sather:12370 In article <1996Mar25.160011.13921@schbbs.mot.com> shang@corp.mot.com writes: >In article bs@research.att.com (Bjarne Stroustrup ><9758-26353> 0112760) writes: >These conditions are not errors but only require some extraordinary work. >Similar examples were also given by Bill Foote in his previous post. >It is not hard for people to figure out more examples that requires the >following struture: 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. 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++. > 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; > } > >is certainly better than: > > result = do_something(); > exceptional_condition = check_error_message(); > while (exceptional_condition) > { > if (exceptional_condition==condition4) > { > result = null; > break; > } > switch (exceptional_condition) > { > case condition1: > some_extraordinary_work1; > do_something(); > break; > case condition2: > some_extraordinary_work2; > do_something(); > break; > case condition3: > some_extraordinary_work3; > do_something(); > break; > } > } 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 ); >Oh, well! It takes me ten time longer to figure out the second piece of >code and I am still not sure whether this code is correct or not. After >a second look, yes, there are errors! "check_error_message()" should also >be called in the loop to get the new exceptional condition after a retry. The error is obscured by poor design/coding, not language features. The example peels off the first loop iteration unnecessarily, leading to extra verbosity and obscuring the loop structure. Arch D. Robison Lead Developer for Photon C++ Kuck & Associates Inc. robison@kai.com 1906 Fox Drive 217-356-2288 Champaign IL 61820