digitalmars.D - Function with try/catch and no return statement
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.
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/
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.
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.
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.
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/
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.
Yields Error: function main.foo no return exp; or assert(0); at end of
function
with dmd 2.041svn on WinXP
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.
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.
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.
"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".
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.
|
C & C++
DMDScript
Stewart Gordon <smjg_1998 yahoo.com> 