www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3020] New: No description is given why function may not be nothrow

reply d-bugmail puremagic.com writes:
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: -------
May 23 2009
next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 22 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 22 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 29 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3020


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #10 from Don <clugdbug yahoo.com.au> 2010-10-29 21:42:16 PDT ---
Fixed svn 736.

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