Program logic bugs vs input/environmental errors

[Tobias Müller via Digitalmars-d]

Walter Bright <newshound2 at digitalmars.com> wrote:
> On 10/4/2014 3:30 AM, Steven Schveighoffer wrote:
>> On 10/4/14 4:47 AM, Walter Bright wrote:
>>> On 9/29/2014 8:13 AM, Steven Schveighoffer wrote:
>>>> I can think of cases where it's programmer error, and cases where it's
>>>> user error.
>>> 
>>> More carefully design the interfaces if programmer error and input error
>>> are conflated.
>>> 
>> 
>> You mean more carefully design File's ctor? How so?
> 
> You can start with deciding if random  binary data passed as a "file
> name" is legal input to the ctor or not.

I think it helps to see contracts as an informal extension to the type
system.
Ideally, the function signature would not allow invalid input at all. In
practice, that's not always possible and contracts are a less formal way to
specify the function signature. But conceptually they are still part of the
signature.

And of course (as with normal contract-less functions) you are always
allowed to provide convenience functions with extended input validation.
Those should then be based on the strict version.

For example take a constructor for an XML document class.
It could take the (unvalidated) file path as string parameter. Or a file
(validated that it exists) object. Or a stream (validated that it exists
and is already opened).
You can provide all three for convenience, but I think it's still good
design to provide three _different_ functions.
Contracts are not a magical tool to provide you all three variants in one
function depending somehow on the needs of the caller.

Tobi