Concept proposal: Safely catching error

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 5 06:13:01 PDT 2017


Olivier FAURE wrote:

> On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:
>>
>> tbh, i think that it adds Yet Another Exception Rule to the language, 
>> and this does no good in the long run. "oh, you generally cannot do 
>> that, except if today is Friday, it is rainy, and you've seen pink 
>> unicorn at the morning." the more exceptions to general rules language 
>> has, the more it reminds Dragon Poker game from Robert Asprin books.
>
> Fair enough. A few counterpoints:
>
> - This one special case is pretty self-contained. It doesn't require 
> adding annotations (unlike, say, DIP PR #61*), won't impact code that 
> doesn't use it, and the users most likely to hear about it are the one 
> who need to recover from Errors in their code.
>
> - It doesn't introduce elaborate under-the-hood tricks (unlike DIP 
> 1008*). It uses already-existing concepts (@safe and @pure), and is in 
> fact closer to the intuitive logic behind Error recovery than the current 
> model; instead of "You can't recover from Errors" you have "You can't 
> recover from Errors unless you flush all data that might have been 
> affected by it".
>
> *Note that I am not making a statement for or against those DIPs. I'm 
> only using them as examples to compare my proposal against.
>
> So while this would add feature creep to the language, but I'd argue that 
> feature creep would be pretty minor and well-contained, and would 
> probably be worth the problem it would solve.

this still nullifies the sense of Error/Exception differences. not all 
errors are recoverable, even in @safe code. assuming that it is safe to 
catch any Error in @safe immediately turns it no unsafe. so... we will need 
to introduce RecoverableInSafeCodeError class, and change runtime to throw 
it instead of Error (sometimes). and even more issues follows (it's 
avalanche of changes, and possible code breakage too).

so, in the original form your idea turns @safe code into unsafe, and with 
more changes it becomes a real pain to implement, and adds more complexity 
to the language (another Dragon Poker modifier).

using wrappers and carefully checking preconditions looks better to me. 
after all, if programmer failed to check some preconditions, the worst 
thing to do is trying to hide that by masking errors. bombing out is *way* 
better, i believe, 'cause it forcing programmer to really fix the bugs 
instead of creating hackish workarounds.


More information about the Digitalmars-d mailing list