try blocks & compound statements

Thread View: comp.std.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Tim Thu, 28 Sep 1995 17:19

#2065

Author: Tim
Date: Thu, 28 Sep 1995 17:19

80 lines
2101 bytes

Greetings,
 
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
	
 
then this scoping issue does not arise.
 
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.
 
comments welcome!
 
regards,
 
- Tim

-- 
--
 Tim Zickus                         "On my fourth day of telecommuting,
 zickus@eecis.udel.edu               I realized that clothes are totally
 http://www.eecis.udel.edu/~zickus   unnecessary"                - Dilbert  

---
[ 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. ]

Re: try blocks & compound statements

#2074

Author: J. Kanze
Date: Fri, 29 Sep 1995 15:21

79 lines
2853 bytes

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. ]

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads