C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  try and non-compound statements          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Pilhofer, Frank Guest Posted: Wed Feb 11, 2004 3:59 pm    Post subject: try and non-compound statements ===================================== MODERATOR'S COMMENT: Since "finally" has been beaten to death here, followup posters please consider limiting their remarks to the proposed construct. Thanks. ===================================== END OF MODERATOR'S COMMENT Hi, [I know the FAQ suggests to read D&E first, but I don't have it around. Is there an online list of accepted/considered/rejected extensions? - FP] According to the C++ standard, the syntax for "try" is try-block: "try" compound-statement handler-seq Now I continue to find myself in the situation where I want to construct an element, handle its exceptions, and then continue using that element. The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers the string of course doesn't exist beyond the try-block. So all you can do is try { std::string foo ("bar"); // use foo } // handle exceptions At that point, you cannot know whether exceptions were raised in the constructor, or while using the string. So I wonder what would happen if the syntax of try-block were changed to allow for non-compound statements (the "statement" rule), e.g. try std::string foo ("bar"); catch (...) {} // use foo This would allow to handle exceptions during construction separately. Does this idea make sense? Or would the above be bad practice? [While talking about exception handling, having a "finally" clause would be nice. But I'm sure I'm not the first to suggest it.] Frank --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Victor Bazarov Guest Posted: Wed Feb 11, 2004 5:29 pm    Post subject: Re: try and non-compound statements "Pilhofer, Frank" <fpilhofe (AT) mc (DOT) com> wrote... Quote: [..] [I know the FAQ suggests to read D&E first, but I don't have it around. Is there an online list of accepted/considered/rejected extensions? - FP] According to the C++ standard, the syntax for "try" is try-block: "try" compound-statement handler-seq Now I continue to find myself in the situation where I want to construct an element, handle its exceptions, and then continue using that element. I wonder how you use "that element" if it fails to construct... Quote: The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers the string of course doesn't exist beyond the try-block. So all you can do is try { std::string foo ("bar"); // use foo } // handle exceptions At that point, you cannot know whether exceptions were raised in the constructor, or while using the string. Aren't you supposed to distinguish those by catching different exceptions? Quote: So I wonder what would happen if the syntax of try-block were changed to allow for non-compound statements (the "statement" rule), e.g. try std::string foo ("bar"); catch (...) {} catch(...) {} is really useless if you really need to Quote: // use foo Wouldn't 'foo' be out of scope here? Just consider other places where a single (non-compound) statement is allowed: if (condition) int a = 42; // a is not available. So, to make it consistent, the scope of 'foo' would have to be limited to the 'try' clause, no? Quote: This would allow to handle exceptions during construction separately. Just keep the exceptions separate, and you'll be able to handle them separately. Quote: Does this idea make sense? Or would the above be bad practice? I'll leave it to experts to judge. V --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Adam H. Peterson Guest Posted: Thu Feb 12, 2004 8:15 pm    Post subject: Re: try and non-compound statements Quote: So I wonder what would happen if the syntax of try-block were changed to allow for non-compound statements (the "statement" rule), e.g. try std::string foo ("bar"); catch (...) {} // use foo I would prefer allowing an "else" clause at the end of the catch sequence, where the else body is considered part of the scope of the try, but if the same exception were to occur in the body, they wouldn't be caught by the catch blocks, and you wouldn't have to resort to exception tunneling or something. Something like this: try { C1 var1(blah); C2 var2(blah2); C3 var3(blah3); } catch (std::range_exception) { whatever(); } else { var1.dosomething(var2,var3); // etc ... } I've run into this situation when I wanted to do exception translation, but only for boost::bad_lexical_cast's that occurred in a construction. In my situation, I ended up with some boost::bad_lexical_cast's that were spuriously translated, until I tunneled the exceptions after the construction. Needless to say, the constructs were not simple. I'm not sure how feasible this is to implement, or to implement without overhead. But compiler implementers have worked some remarkable magic before. Adam H. Peterson --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Nicola Musatti Guest Posted: Fri Feb 13, 2004 2:38 pm    Post subject: Re: try and non-compound statements [email]fpilhofe (AT) mc (DOT) com[/email] ("Pilhofer, Frank") wrote in message news:<C72E341DF733CD42A5523C584505E75408BDC761 (AT) ad-email1 (DOT) ad.mc.com>... [...] Quote: Now I continue to find myself in the situation where I want to construct an element, handle its exceptions, and then continue using that element. The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers If an exception were thrown during foo's construction, you can't trust it to be in any useful state. Why do you want to use it, then? Quote: the string of course doesn't exist beyond the try-block. So all you can do is try { std::string foo ("bar"); // use foo } // handle exceptions At that point, you cannot know whether exceptions were raised in the constructor, or while using the string. If you need to distinguish, either throw different exceptions or use different try blocks: std::string foo ("bar"); try { This(); } catch (...) { } try { That(); } catch (...) { } Cheers, Nicola Musatti --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alan Meyer Guest Posted: Fri Feb 13, 2004 10:14 pm    Post subject: Re: try and non-compound statements ""Pilhofer, Frank"" <fpilhofe (AT) mc (DOT) com> wrote Quote: ... Now I continue to find myself in the situation where I want to construct an element, handle its exceptions, and then continue using that element. The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers the string of course doesn't exist beyond the try-block. Here's one way to do it with the existing standard: std::string *foo; try { foo = new std::string ("bar"); } catch (...) {} // Now we can refer to *foo, foo->... or whatever foo is defined outside the try block but, because it is a pointer and not an object, the constructor is not invoked at the point of definition. That's not as nice as what you propose because it forces you as the programmer to do your own delete(), but it does get around the scoping problem. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alberto Barbati Guest Posted: Sat Feb 14, 2004 5:48 am    Post subject: Re: try and non-compound statements Pilhofer, Frank wrote: Quote: The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers the string of course doesn't exist beyond the try-block. So all you can do is try { std::string foo ("bar"); // use foo } // handle exceptions At that point, you cannot know whether exceptions were raised in the constructor, or while using the string. In fact you can, although the syntax is bit cumbersome: try { std::string foo("bar"); try { // use foo } catch( /* omitted */ ) // handle execeptions raised while using foo {/* omitted */ } } catch( /* omitted */ ) // handle exceptions raised during construction { /* omitted */ } I agree it's ugly, especially because the catch-handlers of the construction statement are physically far from the statement itself. Moreover, an exception thrown while using foo might be caught "involuntarily" by construction catch-handlers. Quote: So I wonder what would happen if the syntax of try-block were changed to allow for non-compound statements (the "statement" rule), e.g. try std::string foo ("bar"); catch (...) {} // use foo the main problem I see with this syntax is: what happens if an exception is thrown and caught and the control reaches the end of the corresponding handler? Of course, the control cannot pass to the next statement, because foo would be in scope but would not have been constructed. It also cannot jump somewhere else because this syntax does not allow the programmer to specify the destination of the jump (jumping to end of the current scope would be very unintuitive IMHO). The only solution I see is to rethrow the exception, in the same way it is done with function-try-blocks of a constructor (15.3/16). Frankly, I never encountered a piece of code that requires this construct, so I don't know how this requirement may affect the usefulness of this syntax. Alberto --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David Abrahams Guest Posted: Sat Feb 14, 2004 10:33 pm    Post subject: Re: try and non-compound statements [email]ameyer2 (AT) yahoo (DOT) com[/email] ("Alan Meyer") writes: Quote: Here's one way to do it with the existing standard: std::string *foo; try { foo = new std::string ("bar"); } catch (...) {} // Now we can refer to *foo, foo->... or whatever foo is defined outside the try block but, because it is a pointer and not an object, the constructor is not invoked at the point of definition. That's not as nice as what you propose because it forces you as the programmer to do your own delete(), but it does get around the scoping problem. ?? Before the catch(...) block is entered, the compiler destroys the pointer and any partially-constructed std::string object if an exception is thrown during the new-expression. -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Victor Bazarov Guest Posted: Sun Feb 15, 2004 9:32 pm    Post subject: Re: try and non-compound statements "Alan Meyer" <ameyer2 (AT) yahoo (DOT) com> wrote... Quote: ""Pilhofer, Frank"" <fpilhofe (AT) mc (DOT) com> wrote in message news:C72E341DF733CD42A5523C584505E75408BDC761 (AT) ad-email1 (DOT) ad.mc.com... ... Now I continue to find myself in the situation where I want to construct an element, handle its exceptions, and then continue using that element. The limitation to a compound-statement, with its corresponding lifecycle issues doesn't make this easy, because in the code try { std::string foo ("bar"); } // some handlers the string of course doesn't exist beyond the try-block. Here's one way to do it with the existing standard: std::string *foo; try { foo = new std::string ("bar"); } catch (...) {} // Now we can refer to *foo, foo->... or whatever foo is defined outside the try block but, because it is a pointer and not an object, the constructor is not invoked at the point of definition. That's not as nice as what you propose because it forces you as the programmer to do your own delete(), but it does get around the scoping problem. Why not use an auto_prt<string>, then? No need to 'delete'... Victor --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Frank Pilhofer Guest Posted: Mon Feb 16, 2004 3:27 am    Post subject: Re: try and non-compound statements Alberto Barbati <AlbertoBarbati (AT) libero (DOT) it> wrote: All right. I see that my problem statement was poorly phrased, and I was misunderstood by some posters. I am not trying to access partially constructed objects, i.e. after a constructor raised an exception. Quote: In fact you can, although the syntax is bit cumbersome: I agree it's ugly, especially because the catch-handlers of the construction statement are physically far from the statement itself. Yes. This is the situation that I was trying to address: handle an exception during construction locally. Continue using the object only if no exception was raised. The other option is the one outlined in Alan's post: construct the object on the heap, using new: then the pointer can be defined before the try statement and remains valid beyond the catch blocks. I am asserting that the exception handlers do not allow the current block's flow to continue (with an uninitialized pointer), but that they either throw a (different?) exception, or return. Alberto's code fragment is of course the correct way to handle exceptions during construction, with the mentioned drawbacks. I share his opinion about its ugliness and was trying to come up with a less ugly option, i.e. where the exception handling is closer to the point of occurence. Frank -- Frank Pilhofer ........................................... [email]fp (AT) fpx (DOT) de[/email] I'm a pessimist so that I can be positively suprised by reality. - FP --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.