On exceptions, errors, and contract violations

[Jacob Carlborg via Digitalmars-d]

On 2014-10-06 16:36, Steven Schveighoffer wrote:

> This is the thing I have been arguing. Inside a library, the idea of
> input to the function being user defined or program-defined is not
> clear. It means that any user-defined input has to be double checked in
> the same exact way, to avoid having an error thrown in the case that the
> library function throws an error on such input. The other side, any
> program-caused errors that end up triggering exceptions (a misnamed
> filename for opening a config file, for instance), needs to treat this
> exception as an error and halt the program with an appropriate stack trace.

I kind of agree with Walter. In an ideal world all environmental errors 
would throw an exception, i.e. a file cannot be found. Any other errors 
would be asserts, i.e. passing null to a function not expecting it.

But I can understand that that behavior would most likely cause problems.

-- 
/Jacob Carlborg