Program logic bugs vs input/environmental errors

[rst256 via Digitalmars-d]

On Saturday, 18 October 2014 at 17:55:04 UTC, Walter Bright wrote:
> On 10/18/2014 9:01 AM, Sean Kelly wrote:
>> So you consider the library interface to be user input?
>
> The library designer has to make that decision, not the 
> language.
>
>
>> What about calls that are used internally but also exposed as 
>> part of the library interface?
>
> The library designer has to make a decision about who's job it 
> is to validate the parameters to an interface, and thereby 
> deciding what are input/environmental errors and what are 
> programming bugs.
>
> Avoiding making this decision means the API is underspecified, 
> and we all know how poorly that works.
>
> Consider:
>
>     /******************************
>      * foo() does magical things.
>      * Parameters:
>      *   x   a value that must be greater than 0 and less than 8
>      *   y   a positive integer
>      * Throws:
>      *   Exception if y is negative
>      * Returns:
>      *   magic value
>      */
>     int foo(int x, int y)
>     in { assert(x > 0 && x < 8); }
>     body {
>        enforce(y >= 0, "silly rabbit, y should be positive");
>        ... return ...;
>     }

Contract Programming. Contract-rider list  all required for this  
  item api conditions. In that case is a list of exseption handler 
on client side.
Epic sample of first post, may be like this:
in {rider(except, "this class may trowing io exception, you must 
defined ...") }