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