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