On 10/16/2014 12:08 PM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 18:49:13 UTC, Walter Bright wrote:
On 10/16/2014 6:46 AM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright wrote:
Don't throw Errors when you need to unwind. Throw Exceptions. I.e. use
enforce() instead of assert().
I'm more concerned about Phobos. If it uses nothrow and asserts in
preconditions then the decision has been made for me.
Which function(s) in particular?
Nothing specifically... which is kind of the problem. If I call
an impure nothrow function, it's possible the function accesses
shared state that will not be properly cleaned up in the event of
a thrown Error--say it contains a synchronized block, for
example. So even if I can be sure that the problem that resulted
in an Error being thrown did not corrupt program state, I can't
be sure that the failure to unwind did not as well.
Contract errors in Phobos/Druntime should be limited to having passed it invalid
arguments, which should be documented, or simply that the function has a bug in
it, or that it ran out of memory (which is generally not recoverable anyway).
I.e. I'm not seeing where this is a practical problem.
That said, I'm inclined to say that this is only a problem
because of how many things are classified as Errors at this
point. If contracts used some checking mechanism other than
assert, perhaps this would be enough. Again I'll refer to my "on
errors" post that gets into this a bit. Using two broad
categories: exceptions and errors, is unduly limiting.
My initial impression is that there's so much confusion about what should be an
Error and what should be an Exception, that adding a third category will not
improve things.
