Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

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.