Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!sunic!newsfeed.ACO.net!Austria.EU.net!EU.net!howland.reston.ans.net!newsfeed.internetmci.com!news.sprintlink.net!new-news.sprintlink.net!news.interserv.net!news1.interserv.net!news From: Jerry Houston 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: Tue, 26 Mar 1996 10:14:24 -0800 Organization: Wall Data - Salsa Products Division Lines: 44 Message-ID: <31583400.4CF9@Salsa.WallData.com> References: <1996Mar25.160702.14229@schbbs.mot.com> NNTP-Posting-Host: 89184.walldata.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0GoldB1 (Win95; I) Xref: news.daimi.aau.dk comp.object:53249 comp.lang.eiffel:22522 comp.lang.c++:175188 comp.lang.beta:10681 comp.lang.java:28775 comp.lang.sather:12360 David L. Shang wrote: [snip] > But I don't see what's wrong with the cynic. It is true that to > implement resumable exceptions in C++ is very hard. It is also > true that resumable exception is useful, see below. [snip] > The definition: > > > "Exception handling is intended to allow code that has encountered > >a condition it cannot cope with to return to some other code that > >directly or indirectly invoked it. There is no way for an exception > >handler to request the thread of control to resume from the throw point. > >In other words, "throw" implements the termination model of exception > >handling." -ARM, Ellis & Stroustrup, page 354 [snip,snip] I agree with the comments you made (and I snipped out), but one point you didn't make in your reply was the location where execution resumes. In the earlier quotation from ARM, "...from the throw point..." is the operative phrase. I think there might be people here who otherwise would be agreeing with each other, that are instead arguing. Resumption from the original invocation of a set of code that might throw an exception (from the try{} block) is considerably different from resumption from the point at which the error was detected. I have used a method such as you described for so long, and with such complete success, that I can't imagine anyone's finding fault with it. For any exception that might warrent user interaction, rather than just a "You're Screwed" message, I always include a [Retry] button for the user to click after first fixing the problem. It passes control to the beginning of the try{} block. (This is one of the few places where my coding standard allows "goto," even in C++.) Obviously, this kind of handling isn't always appropriate, but in a case where execution can sometimes continue based on the user's having intervened in some way (such as moving a file, providing a valid path, shutting down some other process that interferes with this one, etc.)it makes a lot of sense.