On 05/31/2017 10:39 PM, Jonathan M Davis via Digitalmars-d wrote:
On Wednesday, May 31, 2017 22:24:16 Nick Sabalausky via Digitalmars-d
wrote:
On 05/31/2017 05:00 PM, Steven Schveighoffer wrote:
But that ship, as I said elsewhere, has sailed. We can't change it to
Exception now, as that would break just about all nothrow code in
existence.
This is why the runtime needs to guarantee that normal unwinding/cleanup
*does* occur on Error (barring actual corruption or physical
impossibilities, obviously).
It is my understanding that with how nothrow is implemented, that's not
actually possible. The compiler takes advantage of nothrow to optimize out
the exception handling code where possible. To force it to stay just to try
and clean up when an Error is thrown would defeat the performance gains that
we get with nothrow.
Besides, it's highly debatable that you're actually better off cleaning up
when an Error is thrown, because it largely depends on what has gone wrong.
In some cases, it _would_ be better if clean-up occurred, whereas in others,
it's just making matters worse.
What we currently have is a weird hybrid. When an Error is thrown, _some_ of
the clean-up is done, but not all. Whether that's worse than doing no
clean-up is debatable, but regardless, due to nothrow, we can't do all of
the clean-up, so relying on all of the clean-up occurring is error-prone.
And pretty much the only reason that _any_ clean-up is done when an Error is
thrown is because someone implemented it when Walter wasn't looking.
The reality of the matter though is that no matter what we do, a completely
robust program must be able to deal with the fact that it could be killed at
any time (e.g. due to a power outage) - not that it needs to function
perfectly when it gets killed, but for stuff like database consistency, you
can't rely on the program dying gracefully to avoid data corruption.
- Jonathan M Davis
