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);"(); //

 	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