Program logic bugs vs input/environmental errors

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 16 12:31:05 PDT 2014


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.



More information about the Digitalmars-d mailing list