nothrow by default
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sun Jan 5 13:21:51 UTC 2020
On Sunday, 5 January 2020 at 13:12:47 UTC, rikki cattermole wrote:
> The way this delegate get used is that it gets matched bottom
> up (like we do now), in the thrower. The throw statement will
> match the delegate to the exception, call the delegate and then
> proceed to do whatever that function tells it to do. It could
> assert out, return Return.init, continue doing stuff (which may
> lead to asserting out), or unroll to the handling point (which
> is what we want to avoid).
When exceptions were discussed in the 80s/90s people looked at
recovery that kinda works they way you describe. So when a
function fails it can stop and then let some other unit fix the
problem and then resume where it halted.
I guess you could do this with coroutines in some elegant fashion.
The problem is really writing the code in a recoverable fashion,
which most programmers seem to not be able to do, hence the
current "transactional" model of unrolling and the retrying from
With transactional memory and perhaps even a more generic
transactional concept that also covers external resources then
you could have complete unrolling without programmer intervention
(so that no RAII/destructors have to be written). But that is
rather advanced... and more like research topic I guess.
More information about the Digitalmars-d