www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2618] New: Assert errors should be unrecoverable.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618

           Summary: Assert errors should be unrecoverable.
           Product: D
           Version: 2.023
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: dsimcha yahoo.com


void main() {
    foo(1);
}

void foo(int i) nothrow {
    assert(i < 0);
    return i;
}

Compiles in release mode because asserts are disabled.  When asserts are
enabled, compilation fails w/ the following error msg:

test.d|5|function test.foo 'foo' is nothrow yet may throw

Fixing this is necessary to allow some code that doesn't throw any "real"
exceptions, but uses asserts for internal consistency checks, to compile in
debug mode.  Also, if asserts are used in the precondition block instead of in
the body, then the code compiles:

void foo(int i) nothrow
in {
    assert(i < 0);
} body {
    return i;
}


--
Jan 25 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618






Counter point.. how would one unit test proper assertions should they become
non-catchable?  For example:

void foo(int i) {
    assert(i != 3, "don't ask me why, but 3 is illegal");
}

unittest {
    try {
        foo(3);
        assert(false, "should not have reached here");
    } catch (AssertError e) {
        assert(e.msg() == "don't ask me why, but 3 is illegal");
    }
}

(typed on the fly, so forgive any minor errors and worry about the desired
behavior)


--
Jan 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618






Well, IMHO, asserts are supposed to be for pre- and postconditions and internal
consistency checks and are essentially tests in themselves.  Unittesting the
asserts, then, is just plain overkill.  If it's the kind of thing were it's
more than just a sanity check, then you probably should be using "real"
exceptions anyhow.  Honestly, I've heard of people testing for "regular"
exceptions being thrown when they should be, but never asserts.


--
Jan 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618






David - I agree with Brad. Sometimes the assertion in a precondition can be
quite complicated. I've occasionally inserted tests to check it.
(A precondition in a LIBRARY function is a test for USER code. Not a test for
the library code).

However, as I see it, asserts are basically a debugging feature. So they
shouldn't interfere with nothrow.

I wonder if assert could be made unrecoverable inside a nothrow function?
IE, compiles to d_assert_nothrow()
which tests the condition, and immediately quits if it is not met?

Since assert() is magical already.


--
Jan 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618






Yes, but what makes this bug even more ridiculous (take another look at the
original report) is that asserts only interfere w/ nothrow if they're in the
body of the function.  If they're in the precondition block, then they don't.


--
Jan 26 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2618


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com





ISTM the optimisations brought about by nothrow should be enabled only in
release mode.  So it would still be possible to catch the assert errors for
testing purposes.


--
Jan 27 2009