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

           Summary: finally block not executed for assertions
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dawg@dawgfoto.de


--- Comment #0 from dawg@dawgfoto.de 2011-11-26 15:01:32 PST ---
void main(string[] args)
{
    try
    {
        assert(args.length > 1);
    }
    finally
    {
        extern(C) void printf(const char* format, ...);
        printf("finally\n");
    }
}

---

The issue is that AssertExp is marked as nothrow.


This bug is responsible for the deadlocks in druntime unittests.

synchronized(foo)
{
  assert(exp);
}

is rewritten as

_d_monitorenter(__sync);
assert(exp);
_d_monitorexit(__sync);

-- 
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=7018


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |INVALID


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2011-11-26 20:45:19 PST ---
The behavior is correct. assert throws a non-recoverable exception, which means that finally blocks are not executed.

If a test depends on finally being executed after an assert, then the test case is wrong.

-- 
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=7018


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |braddr@puremagic.com
         Resolution|INVALID                     |
            Summary|finally block not executed  |synchronized + assert ==
                   |for assertions              |evil results


--- Comment #2 from Brad Roberts <braddr@puremagic.com> 2011-11-26 21:40:25 PST ---
I'm going to re-open for a second.  I don't disagree with the part about assert + try/catch/finally, I agree that there's, at a minimum, a diagnostic issue here.

There's no case in which synchronized { assert } is valid.

Additionally, if this is indeed the source of the druntime deadlock, THAT bug isn't invalid and still needs to be fixed.

-- 
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=7018



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2011-11-26 22:08:27 PST ---
(In reply to comment #2)
> There's no case in which synchronized { assert } is valid.

There is because assert is for checking for logic errors, and then it is supposed to abort the program. It is not expected to clean up finally blocks, release mutexes, etc.

AssertExp *is* nothrow.

If there are bugs in the druntime tests, those need to be identified and submitted.

-- 
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=7018



--- Comment #4 from dawg@dawgfoto.de 2011-11-27 04:34:47 PST ---
I agree with nothrow.
Not sure how to handle synchronized { assert }.
Maybe the root cause is that the runtime fails to abort
a program with Errors being thrown in different threads, is it?

-- 
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=7018


Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean@invisibleduck.org


--- Comment #5 from Sean Kelly <sean@invisibleduck.org> 2011-11-30 16:34:21 PST ---
If no cleanup should be performed, why is an assertion failure represented as an exception in the first place?  And what about the other Errors that can legally be generated within a nothrow block (like OutOfMemoryError) but are technically recoverable?

-- 
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=7018


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

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


--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-11-30 16:57:07 PST ---
They're Errors, not Exceptions, so they are _not_ expected to be recoverable. The fact that they are exceptions allows you to get more meaningful data on failures (e.g. stack traces), and you _can_ technically recover from them in very controlled circumstances but _only_ in very controlled circumstances where you really know what you're doing and you're very careful to make sure that it's actually safe to do the recovery. In the general case, they are _not_ expected to be recoverable and so are not treated that way. Once an Error is thrown, the program is in an undefined state, so it's questionable that you even _can_ recover except in very controlled circumstances.

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