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.
