nothrow by default

rikki cattermole rikki at cattermole.co.nz
Sun Jan 5 13:32:24 UTC 2020


On 06/01/2020 2:21 AM, Ola Fosheim Grøstad wrote:
> 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.


Yeah there are quite a few variations on this model and I only know the 
basics.

I don't think we would need the exception handler delegate to "fix" the 
problem per-say, only determine what the user code wants to do. But 
perhaps a company like WekaIO has a use case I haven't thought about 
that would make this a killer feature for them.

> 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 scratch.

Yes. IMO the two most likely used out comes would be rethrows or to 
return prematurely.

> 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.


When I described unrolling, I do mean unrolling using the exception 
handling mechanism.



Just an idea:

try {

} catch(Exception e) {
//	continue throw;
//	continue;
//	break;
}

Any of the statements in the catch block would opt-in to this new 
mechanism, with the default remaining what we have now.

We could also support some sort of typedef'd tuple or random struct's, 
that would force into this new mechanism and default to assert(0);


More information about the Digitalmars-d mailing list