Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!news1.transpac.net!news2.transpac.net!www.netman.se!aftonbladet.se!seunet!mn7.swip.net!mn6.swip.net!plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!newsfeed.internetmci.com!in1.uu.net!hoho.quake.net!usenet From: billf@jovial.com (Bill Foote) 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: 29 Mar 1996 07:55:27 GMT Organization: Jovial Lines: 141 Message-ID: <4jg51f$n99@hoho.quake.net> References: <4j954n$mrq@kai.com> <1996Mar27.211117.5569@schbbs.mot.com> <4jefbd$k33@kai.com> NNTP-Posting-Host: l89.ip.quake.net Xref: news.daimi.aau.dk comp.object:53412 comp.lang.eiffel:22575 comp.lang.c++:175670 comp.lang.beta:10693 comp.lang.java:29698 comp.lang.sather:12374 In article <4jefbd$k33@kai.com>, Arch Robison wrote: >In article <1996Mar27.211117.5569@schbbs.mot.com> shang@corp.mot.com writes: >>If resumption semantics were inferior, why should we bother to get >>its "benefits" by simulating its semantics as below: > >I should have qualified my statement "inferior" to "inferior in most cases". I'm still puzzled how providing *additional* functionality can make resumable exception semantics "inferior" (except for implementation considerations), but that's a nit. > 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 ); Well, here I go again, disagreeing with Bjarne, but: This example misses the point of resumable exceptions. If you can sensibly catch the exception at the point from which you want to resume, yes, of course, you don't need resumable execeptions. Resumable exceptions only buy you something if the point where you can deal with the exception is one or more stack frames _above_ the point where the error occurs. Here is an example of something that you can't simulate with termination semantics: main() { try { call_something(); } catch ( OutOfMemoryException& ex) { do_something_to_free_up_some_memory(); if (a_decent_amount_of_memory_was_freed()) retry; } } void call_something() { <...> call_something_else(); } void call_something_else() { <...> try { auto_ptr = malloc(A_REALLY_BIG_NUMBER); } } The idea here is that the only place with enough context to know how to free up some memory (perhaps by flushing some caches or something) is main(). call_something_else() exists at too low a level to know how to do that. If memory is low, the malloc() fails, and the exception handler in main() catches it, and then resume causes execution to go back to the point of failure. Now, Bjarne's claim is that, in practice, doing this sort of thing isn't useful. He backs this up with reports of real-world experience, where large systems were built, and resumption semantics were found to not be useful, in practice. This contention I cannot disagree with -- I don't have any experience with large systems using resumption semantics for its exceptions. It's pretty easy to concoct toy example where it seems compelling, but that doesn't really demonstrate that, in practical terms, it's useful. (Of course, three or four case studies doesn't guarantee that it *isn't* useful, but it certainly supports the contention). Does anyone out there know of examples from large systems where resumption semantics proved valuable? >The original attack on C++ unfairly implied that the C++ committee had given no >though to the issues. As the author of the "attack", I respectfully disagree. I did not mean to imply that the C++ committee gave no thought to the issue. I *did* imply that the fact that implementing resumable exceptions would be hard may have influenced the decision of the committe to not support them. (Incidentally, I did not think of my comment as an "attack". Perhaps a "jibe", or "poking fun", but attack is much too strong a word.) >As described in Stroustrup's D&E book, the C++ committee >knowledgeably debated the resumption vs. termination models of exception >handling and judged that the extra cost of the resumption model was not worth >the cost in added complexity. Exactly. Given the definition of C++, it would be hard to implement resumable exceptions. This may have played into the decision not to do it. I think we're in violent agreement :-) >Thus many apparently useful features are deliberately left out of C++ . >Users who want the features can simulate them without burdening others. Aak! Some things are very, very difficult to "simulate" without runtime support from the language. Off the top of my head: * Simulating MI in a SI language would be tough * Block closures, and curried functions. * Garbage Collection (with, of course, finalization and weak references) is hard to "simulate". (Not impossible, but much, much harder than if it's put in the language). * Resumable exceptions * Meta-information. (For example, try to write a framework that automatically "pickles" an arbitrary C++ object. You end up either forcing the client to write his own pickling/unpickling code, or relying on a preprocessor. Both are painful.) * RTTI a la C++. dynamic_cast is *awfully* hard to "simulate" for all but trivial uses in a pre-RTTI C++ compiler. >C++ is not intended to be the best language for all problems. >If another language is better for your problem, use it. Of course. But does that mean that all critical thought as to the merits of C++ should stop? I certainly hope not! -- Bill Foote | L'homme est né pour vivre dans les billf@jovial.com | convulsions de l'inquiétude ou dans la http://www.jovial.com/~billf/ | léthargie de l'ennui -- Voltaire