Re: Where shoul I throw RuntimeException
Giovanni Azua wrote:
"Lew" <lew@lewscanon.com> wrote
You use assertions to prove that your validation checks
are correct
It is a paraphrase of what Sun's document says. It is
also consistent with every expert document on assertions
No, it is not part of the document I referred to:
http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html
That document says:
"... place an assertion at any location you assume will not be reached."
That would be a place that your validation checks force to be bypassed if
input is invalid.
void foo() {
for (...) {
if (...)
Here is the validation check.
return;
}
assert false; // Execution should never reach this point!
Here is the assertion that proves the validation check is correct.
}
And later,
public BigInteger modInverse(BigInteger m) {
if (m.signum <= 0)
throw new ArithmeticException("Modulus not positive: " + m);
Here is the validation check.
... // Do the computation
assert this.multiply(result).mod(m).equals(ONE) : this;
And here is the assertion that proves it.
return result;
As you can see, my description of assertions as proof of a validation step is
a paraphrase of the information in that document.
Assertions are part of a *formal* design-by-contract
methodology.
Not true, design-by-contract has e.g. [sic] subcontracting inheritance semantics,
and assertions do not
http://archive.eiffel.com/doc/manuals/technology/contract/page.html see "8-
Interestingly, that same website, at
<http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html>
says,
Eiffel encourages software developers to express formal properties
of classes by writing assertions
As you can see, while assertions certainly can be used informally, they are
also part of a formal approach. As you would know if you yourself knew about
design-by-contract, or even thoroughly read the very sources you cite.
Contracts and Inheritance". If you knew design-by-contract you would also
know that.
Clearly I do know design-by-contract, as evidenced by the very authorities to
whom you yourself appeal.
You need to understand design-by-contract and judging by your
explanations I
think you don't.
Huh?
Indeed you don't.
And yet I have been able to support my claims with direct evidence instead of
/ad hominem/ attacks, even using your own authorities.
Consider
<http://c2.com/cgi/wiki?DesignByContract>
Design By Contract (DbC) is a software correctness methodology.
It uses preconditions and postconditions to document
(or programmatically assert)
Note well!
the change in state caused by a piece of a program.
You also invalidate your own earlier claim that assertions can be used
to validate inputs in a public method. If assertions are disabled in
production, as you and I agree they normally should be, they will not
work as a validation mechanism.
This proofs just one more time that you don't understand the concept of
what's being discussed. Assertions are enabled while testing so, when you
are sure that such public method will under no circumstance ever receive a
e.g. [sic] null value then you roll into production with assertions disabled
But you can never be sure of that! You have no control over how client code
will call the method. No matter how much you test a method that should not
accept a 'null', it could still happen in production, and if you do not
protect against that with an actual runtime check, your code will bomb.
That's the reason why assertions do not protect public methods, and why the
Sun document and everyone who "actually knows what they're doing" decries your
advice.
because the assertion check is not necessary in production e.g. [sic] some
filtering API layer way above may ensure this.
Design-by-contract, as evidenced by the authorities cited, would have the
preconditions and postconditions enforced by the API code itself.
Lew:
I'm only "undermining" your incorrect statements. I don't agree that
allowing misinformation to stand is synonymous with "interesting".
Giovanni:
No, you are only deceiving big time.
I keep providing evidence, source after source, and you keep insulting me.
I would sincerely recommend anyone interested in the topic to look into the
authoritative source and make your own conclusions rather than following the
Lew's simplified summary of what is what:
http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=sr_1_1?ie=UTF8&s=books&qid=1242945595&sr=8-1
Allow me to cite yet more authoritative sources:
<http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ317_005.htm>
<http://en.wikipedia.org/wiki/Assertion_(computing)>
particularly
<http://en.wikipedia.org/wiki/Assertion_(computing)#Assertions_in_design_by_contract>
Note that the Wikipedia article's Java example does exactly what I describe:
validates a condition with the 'if' statement, then proves it with the 'assert'.
<http://en.wikipedia.org/wiki/Assertion_(computing)#Assertions_in_design_by_contract>
and, of course,
<http://en.wikipedia.org/wiki/Design_by_contract>
So far every authority, including those you've cited, has supported what I've
said. DbC is about having the code "ensure" (as Eiffel would say) that the
contract is met. Your suggestion, that disabled assertions can do that, is
false on the face of it.
Now do try to argue on the basis of logic and evidence instead of name-calling
henceforth, hm?
--
Lew