www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Function with try/catch and no return statement

reply Jacob Carlborg <doob me.com> writes:
The following code does not cause a compile error:

int foo ()
{
	try
		int i;
	
	catch (Exception)
		throw new Exception("");
}

Wouldn't it be quite obvious for the compiler to see that there is no 
return statement in the above function and give a compile error? The 
same also happens with scope(failure).

Mac OS X 10.5.7 dmd 1.056.
Feb 06 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-06 08:20:13 -0500, Jacob Carlborg <doob me.com> said:


 The following code does not cause a compile error:
 
 int foo ()
 {
 	try
 		int i;
 	
 	catch (Exception)
 		throw new Exception("");
 }
 
 Wouldn't it be quite obvious for the compiler to see that there is no 
 return statement in the above function and give a compile error? The 
 same also happens with scope(failure).


I'd say it's as it should. Even though in this particular situation 
there is no way the catch block will be used, it's needed for generic 
programming. Consider this:

	int foo(string code)()
	{
		try
			mixin(code);
		
		catch (Exception)
			throw new Exception("");
	}

	foo!"int i;"(); // same as your example
	foo!"writeln(1);"(); // this one might throw

It'd be quite ridiculous if the compiler refused to instantiate the 
first only because it cannot throw. The same rules apply inside a 
regular function.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 06 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 06 Feb 2010 09:42:37 -0500, Michel Fortin wrote:


 On 2010-02-06 08:20:13 -0500, Jacob Carlborg <doob me.com> said:
 

 The following code does not cause a compile error:
 
 int foo ()
 {
 	try
 		int i;
 	
 	catch (Exception)
 		throw new Exception("");
 }
 
 Wouldn't it be quite obvious for the compiler to see that there is no
 return statement in the above function and give a compile error? The
 same also happens with scope(failure).


 
 I'd say it's as it should. Even though in this particular situation
 there is no way the catch block will be used, it's needed for generic
 programming. Consider this:
 
 	int foo(string code)()
 	{
 		try
 			mixin(code);
 		
 		catch (Exception)
 			throw new Exception("");
 	}
 
 	foo!"int i;"(); // same as your example foo!"writeln(1);"(); // 


this

 	one might throw
 
 It'd be quite ridiculous if the compiler refused to instantiate the
 first only because it cannot throw. The same rules apply inside a
 regular function.


The difference is, in this case the generic foo doesn't need to be 
analyzed before it has been instantiated. There is no foo(string code) 
instances in the final executable, only the concrete instantiations. The 
analysis could be done when foo!(something) is encountered in the code.
Feb 06 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
retard wrote:
<snip>

 The difference is, in this case the generic foo doesn't need to be 
 analyzed before it has been instantiated. There is no foo(string code) 
 instances in the final executable, only the concrete instantiations. The 
 analysis could be done when foo!(something) is encountered in the code.


It already is.  It's part of how templates work: templates aren't 
semantically analysed, only instances of them are.

The problem lies in how the requirement for return statements is 
specified, as I've explained in my reply to Michel.

Stewart.
Feb 07 2010
prev sibling parent reply Trass3r <un known.com> writes:
 I'd say it's as it should. Even though in this particular situation  
 there is no way the catch block will be used, it's needed for generic  
 programming. Consider this:


What the hell are you talking about? His post isn't about throwing  
exceptions.
There is no return statement and it compiles nevertheless.
Feb 06 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-06 10:13:39 -0500, Trass3r <un known.com> said:


 I'd say it's as it should. Even though in this particular situation  
 there is no way the catch block will be used, it's needed for generic  
 programming. Consider this:


 
 What the hell are you talking about? His post isn't about throwing  exceptions.
 There is no return statement and it compiles nevertheless.


Ah, oops, sorry. Looks like I couldn't even read properly the 
explanation. You're right of course.

That should be filled as a bug.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 06 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Michel Fortin wrote:
<snip>

 That should be filled as a bug.


Technically it isn't a bug: the rule in the spec is

http://www.digitalmars.com/d/1.0/statement.html#ReturnStatement
"At least one return statement, throw statement, or assert(0) expression 
is required if the function specifies a return type that is not void, 
unless the function contains inline assembler code."

However, I do think it ought to be instead

"At least one return statement is required if the function specifies a 
return type that is not void, unless all possible paths through the code 
lead to a throw statement or assert(0) or the function contains inline 
assembler code."

Additionally or alternatively, one could add a further restriction: "At 
least one return statement [...] that is not within a catch or 
scope(failure) block is required"...

Stewart.
Feb 07 2010
prev sibling next sibling parent Trass3r <un known.com> writes:
Yields Error: function main.foo no return exp; or assert(0); at end of  
function
with dmd 2.041svn on WinXP
Feb 06 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Jacob Carlborg wrote:

 The following code does not cause a compile error:
 
 int foo ()
 {
     try
         int i;
     
     catch (Exception)
         throw new Exception("");
 }
 
 Wouldn't it be quite obvious for the compiler to see that there is no 
 return statement in the above function and give a compile error? The 
 same also happens with scope(failure).
 
 Mac OS X 10.5.7 dmd 1.056.


It gives an error for me on Windows when compiled with -w. If it doesn't 
on Mac, that's definitely a bug.
Feb 06 2010
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don wrote:
<snip>

 It gives an error for me on Windows when compiled with -w. If it doesn't 
 on Mac, that's definitely a bug.


That's strange.  Setting -w shouldn't add any errors.  Only warnings.

Stewart.
Feb 07 2010
next sibling parent Don <nospam nospam.com> writes:
Stewart Gordon wrote:

 Don wrote:
 <snip>

 It gives an error for me on Windows when compiled with -w. If it 
 doesn't on Mac, that's definitely a bug.


 
 That's strange.  Setting -w shouldn't add any errors.  Only warnings.
 
 Stewart.


Actually this is something which recently went from being horribly 
unreliable and annoying, generating error messages on perfectly valid 
code, to being an excellent, trustworthy error. It's ready to become a 
full-grown error now. Also 'length' shadowing inside array slices should 
be an error, not a warning.
Feb 07 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:hkmjms$m7$2 digitalmars.com...

 Don wrote:
 <snip>

 It gives an error for me on Windows when compiled with -w. If it doesn't 
 on Mac, that's definitely a bug.


 That's strange.  Setting -w shouldn't add any errors.  Only warnings.


DMD doesn't have warnings. Just optional errors added by "-w" that are 
mislabeled as "warnings".
Feb 07 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2/6/10 16:19, Don wrote:

 Jacob Carlborg wrote:

 The following code does not cause a compile error:

 int foo ()
 {
 try
 int i;
 catch (Exception)
 throw new Exception("");
 }

 Wouldn't it be quite obvious for the compiler to see that there is no
 return statement in the above function and give a compile error? The
 same also happens with scope(failure).

 Mac OS X 10.5.7 dmd 1.056.


 It gives an error for me on Windows when compiled with -w. If it doesn't
 on Mac, that's definitely a bug.


I does give an error if I compile with -w, but I think it should be an 
error even without -w.
Feb 07 2010