Tim Driven Development | Test until the fear goes away
The example precondition ensures that the argument f of function sqrt() is greater than or equal to zero. Clients who use that method are responsible for adhering to that precondition. If they don't, we as implementors of sqrt() are simply not responsible for the consequences.
Tim Cooke wrote:I've been writing Java since 2006. Never heard of them, never used them, not planning on starting now.
Junilu Lacar wrote:
I sure hope not. This is the kind of thing that can drive developers to madness, literally.
Dave Tolls wrote:I can (possibly) see that sort of thing in engineering/scientific environments, maybe, where your algorithms are fairly tightly defined.
But even then, I would have thought a regular text JavaDoc that simply said what the algorithm was would be enough.
Tim Driven Development | Test until the fear goes away
The text that Junilu bolded is correct; such errors are the responsibility of the client not the supplier. If as in the iContract example, it is a true precondition, then the method does not have to work correctly if it is not fulfilled. It is allowed to behave arbitrarily, fail to terminate, return a nonsense value (like the NaN for passing a negative argument), throw an Exception or something else. The method cannot accept responsibility for an incorrect argument. The worst possible case is that damage is done to the integrity of the object causing its to breach its invariants, but that damage is not noticeable until an incorrect result is obtained later on. It is best practice to document what actions are taken in case of an incorrect argument, whether returning a nonsense value (as sqrt does, but see the cbrt method shown by scrolling down the link one method), taking no action, or throwing an Exception, as this constructor does.If a precondition fails, a bug is in a software component's client.
When I was teaching preconditions postconditions and invariants, I found how you can create a Color instance with (0, 0, 0, 0xff00) and it comes out bright green. I told the students, “A pint of beer for the first person who tells me how I managed that.”A few minutes ago, I wrote:. . . It is impossible to try to get a blue brighter than bright by passing (0, 0, 0, 0xff00) instead of the correct (0, 0, 0, 0xff).
Campbell Ritchie wrote:
The text that Junilu bolded is correct;If a precondition fails, a bug is in a software component's client.
Design by Contract is not new ... The concepts behind the DbC comment style are correct, but the format is incorrect. There is a Java® code style format and there has been for a long time, and the javadoc tool requires that format, so you shouldn't change it.
My opinion of Elizabeth who taught me Java® continues to rise. She taught us about using assertions and pointed out they can be enabled and disabled. Assertions are for testing time in development; the assertive way to handle arguments which don't fulfil the preconditions at runtime is IllegalArgumentException.Junilu Lacar wrote:If you dig even deeper into the course materials, you'll see that the Java code that enforces preconditions uses assert. . . .
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|