Corrupt Unwinding on Errors

[Iain Buclaw]

On Tue, 22 Jan 2019 at 09:15, Eyal Lotem via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> Hi,
>
> I've hit a serious bug due to skipped dtors when errors are being
> thrown.
>
> Whether dtors will run or be skipped is quite unpredictable, as
> it depends on `nothrow` inference[1].
>
> dtors are often absolutely crucial for program correctness, and
> skipping them is very dangerous.
>
> Thus, unwinding while skipping dtors may easily create
> corruption, so I'll term this "corrupt unwinding".
>
> During corrupt unwinding, running scope() code is dangerous - as
> it runs in a potentially corrupt state, and indeed a PR exists to
> not run scope() code in this state [2].
>
> The question is, why have corrupt unwinding at all?
>
> If errors thrown should not properly unwind - why not call a
> tls-installed handler before terminating the program (with no
> unwinding)?
>
> If errors do unwind - why not run the dtors and allow actual
> recovery? The performance cost for predictable, sane semantics is
> well worth it.
>

Throwing an Error inside a nothrow function is allowed, unlike an
Exception.  As for what happens if that were to ever happen is
undefined, because you're not supposed to recover from it.

-- 
Iain