🚀 go-pugleaf

Tim (zickus@eecis.udel.edu) wrote:

|> I am curious as to why the try block has the syntax of:
|>  
|> 	try <compound-statement> <handler-list>
|>  
|>  
|> instead of:
|>  
|> 	try <statement> <handler-list>
|>  
|>  
|> The specific context which prompted me to investigate this issue is
|> that of a constructor which can throw an exception:
|>  
|>  
|> 	class CFoo {
|>  
|> 		class FooError { };
|> 		
|> 		CFoo(int bar) { if (bar>4) throw(FooError); }
|> 	}
|>  
|> 	...
|>  
|> 	{
|>  
|> 	    try {
|> 	        CFoo x(1);
|>  
|> 	        // x is destructed here!
|> 	    }
|> 	    
|> 	    catch (FooError) {
|> 	    ...
|> 	    }
|>  
|> 	    x.SomeMember(); // error: x is out of scope here
|> 	}

|> Note that because the compount statement is required, x is created
|> and destroyed within the try block.

|> If the try block could be written without the compound statement, i.e.
|>  
|> 	try CFoo x(1);
|>  
|> 	catch (FooError) {
|> 	    ...
|> 	}
|>  
|> 	x.SomeMember(); // ok, x is still in scope

This looks like the very answer to your question.  If the constructor of
x throws an exception, you don't have a completely constructed x, and
any attempt to access it is undefined behavior.

|> then this scoping issue does not arise.

This scoping looks more like an advantage to me.

|> I realize that this can be worked-around using a larger try block that
|> encompasses the entire life-span of the constructed object, or by using
|> "new" and a pointer that exists before the try block.  Both of these
|> solutions seem less palatable in some situations than using the single
|> statement.

Note that neither of your suggestions allows accessing the object which
threw the exception.  I believe that this is (and should be) the intent.

-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]