Re: 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 ...") }