http://d.puremagic.com/issues/show_bug.cgi?id=9704
Summary: Destructor not called on function calls if postblit
throws
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody puremagic.com
ReportedBy: johannespfau gmail.com
--- Comment #0 from Johannes Pfau <johannespfau gmail.com> 2013-03-12 11:35:39
PDT ---
See the attached testcase:
If the throw statement in B's postblit is commented we see the expected result:
A:this(this)
B:this(this)
A:~this
B:~this
B:~this
A:~this
The function call creates two copies, then the destructors are called for the
originals and for the copies. But if the throw statement is in place:
A:this(this)
B:this(this)
B:~this
A:~this
object.Exception test99.d(12): Boom
We see that the destructors for the copies are not called. It can be argued
that this is valid for the B copy, as it's postblit threw.
But for the copy of A the destructor must be called as the postblit was called
and succeeded.
The problem is that the destructors are currently called in the callee but the
postblits in the caller. If an exception is thrown in between those calls, the
destructor can't be called.
A possible solution is to move the destructor to the caller. But in this case
the parameter (the copy) must be passed by invisible reference so that the
destructor actually sees the updated value after the callee returns.
(Note that it might be useful to make an exception for non-PODs without
destructors here. Those shouldn't be affected by this issue and could be
treated like PODs when being passed to a function as an optimization.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

A possible solution is to move the destructor to the caller. But in this case
the parameter (the copy) must be passed by invisible reference so that the
destructor actually sees the updated value after the callee returns.
(Note that it might be useful to make an exception for non-PODs without
destructors here. Those shouldn't be affected by this issue and could be
treated like PODs when being passed to a function as an optimization.)