http://d.puremagic.com/issues/show_bug.cgi?id=3020

           Summary: No description is given why function may not be
                    nothrow
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: diagnostic
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: 2korden@gmail.com


import std.stdio;

int foo(int i, int j) nothrow
{
    return i + j;
}

int bar() nothrow
{
    return 0;
}

void test() nothrow
{
    int x = bar();
    int y = foo(x, x);
    writefln("%d, %d", x, y);
}

void main()
{
    test();
}

Expected output:
test.d(13): Error: function test.test 'test' is nothrow yet writefln at
test.d(17) may throw

Actual output:
test.d(13): Error: function test.test 'test' is nothrow yet may throw

Rising its severity because the feature is barely usable without appropriate error messages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2010-09-17 23:38:10 PDT ---
I'm not sure that I agree that this bug is "critical," since dmd works fine with this bug. It's just highly annoying. But as it is highly annoying, it would definitely be nice to have this fixed. If you're trying to make your code use nothrow as much as possible (which I would think would be ideal, just as you'd try and use const as much as possible), this bug really gets in the way. It's not fatal, but it sure is annoying.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #2 from bearophile_hugs@eml.cc 2010-09-19 17:46:06 PDT ---
This isn't a critical bug. There are FAR worse bugs in DMD that are rated as normal bugs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020



--- Comment #3 from Don <clugdbug@yahoo.com.au> 2010-10-22 17:16:07 PDT ---
Created an attachment (id=790)
patch against svn 724

This is a big patch, but it's very simple. When checking for the return type of functions, the info about whether it is a nothrow function is passed as a parameter. If it throws from inside a nothrow function, it generates an error message.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020



--- Comment #4 from Don <clugdbug@yahoo.com.au> 2010-10-22 17:23:09 PDT ---
For the initial test case, the error messages are:

test.d(17): Error: writefln is not nothrow
test0.d(13): Error: function test0.test 'test' is nothrow yet may throw

Another example:
=======
import core.exception;

void foo() nothrow
{
    try {
    throw new Exception("xxx");
    } catch(Exception e) {
    auto z = new int;
    throw e;
    }
}
----
test.d(8): Error: 'new int' may throw OutOfMemoryError
test.d(9): Error: object.Exception is thrown but not caught
test.d(3): Error: function test0.foo 'foo' is nothrow yet may throw

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2010-10-29 03:21:11 PDT ---
Out of memory errors should be allowed inside nothrow.

Also, I suspect it would be good to disallow:

try
{
   ...
}
catch (Exception e)
{
   /* nothing here */
}

where all exceptions are swallowed and ignored. This kind of thing happens in Java to work around exception specifications, but I don't see a need for it here. Of course, there would still be ways to swallow & ignore (just put in a call to a do-nothing function), but such shouldn't be easy.

What do you think?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2010-10-29 03:21:11 PDT ---
Out of memory errors should be allowed inside nothrow.

Also, I suspect it would be good to disallow:

try
{
   ...
}
catch (Exception e)
{
   /* nothing here */
}

where all exceptions are swallowed and ignored. This kind of thing happens in Java to work around exception specifications, but I don't see a need for it here. Of course, there would still be ways to swallow & ignore (just put in a call to a do-nothing function), but such shouldn't be easy.

What do you think?

--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2010-10-29 03:37:35 PDT ---
There are plenty of cases where you know that a function will never throw but
it's not nothrow (perhaps because it can throw in other circumstances), and
you're forced to catch the Exception anyway (probably because you're in a
nothrow function). Personally, I use assert(0) for such cases.

As long as disallowing empty catch blocks is really for _empty_ catch blocks (or catch blocks with only a comment), I don't mind. But there are definitely cases where you want to eat an exception or where there should never be one but you have to have a try-catch anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020



--- Comment #7 from Don <clugdbug@yahoo.com.au> 2010-10-29 05:30:34 PDT ---
(In reply to comment #5)
> Out of memory errors should be allowed inside nothrow.

Good. I think so too. That will make nothrow much more useful.
In the existing compiler, they are disallowed.
( void foo() nothrow { auto x = new int; }  won't compile).
I just added error messages to specify why it was being disallowed.

It sounds as though the check for nothrow violations should be separated from
the code which determines if a statement can throw. That is, for 'new' and for
asm, we assume that it can throw. But, if it's in a nothrow function, we trust
the programmer.
Then, what happens if an out of memory condition happens in a nothrow function?
Is the program simply terminated?

> 
> Also, I suspect it would be good to disallow:
> 
> try
> {
>    ...
> }
> catch (Exception e)
> {
>    /* nothing here */
> }
> 
> where all exceptions are swallowed and ignored. This kind of thing happens in Java to work around exception specifications, but I don't see a need for it here. Of course, there would still be ways to swallow & ignore (just put in a call to a do-nothing function), but such shouldn't be easy.
> 
> What do you think?

Dunno. It's certainly bad style.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020



--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> 2010-10-29 10:29:39 PDT ---
(In reply to comment #7)
> In the existing compiler, they are disallowed.

That's a bug.

> ( void foo() nothrow { auto x = new int; }  won't compile).
> I just added error messages to specify why it was being disallowed.
> It sounds as though the check for nothrow violations should be separated from
> the code which determines if a statement can throw. That is, for 'new' and for
> asm, we assume that it can throw. But, if it's in a nothrow function, we trust
> the programmer.
> Then, what happens if an out of memory condition happens in a nothrow function?
> Is the program simply terminated?

Yes.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3020


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #9 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-10-29 11:11:26 PDT ---
(In reply to comment #5)
> Out of memory errors should be allowed inside nothrow.
> 
> Also, I suspect it would be good to disallow:
> 
> try
> {
>    ...
> }
> catch (Exception e)
> {
>    /* nothing here */
> }
> 
> where all exceptions are swallowed and ignored. This kind of thing happens in Java to work around exception specifications, but I don't see a need for it here. Of course, there would still be ways to swallow & ignore (just put in a call to a do-nothing function), but such shouldn't be easy.
> 
> What do you think?

There are plenty of cases when you want to swallow exceptions, and it's highly unlikely that anyone would write such a pattern by mistake. So let's keep allowing it. At best, the compiler could protest that "e" is not being used and ask for a nameless catch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------