Re: Where shoul I throw RuntimeException
Lew wrote:
All you can do is put in validation checks, using exceptions
or default return values. You use assertions to prove that your
validation checks are correct, as part of your thorough testing, not
as a replacement for validation checks.
Giovanni Azua wrote:
I think this is wrong.
It is a paraphrase of what Sun's document says. It is also consistent
with every expert document on assertions that I've seen, not limited
to the Java implementation thereof. Sun's document explicitly teaches
that assertions are not to be used to check argument validity for
public methods. I've quoted the relevant text from that document
upthread.
One pattern is to assert after possibly throwing an exception.
if ( arg == null )
{
throw new NullPointerException( "Null arg not allowed." );
}
assert arg != null;
Giovanni Azua wrote:
Besides, assertions were introduced in Java as an "informal" design by co=
ntract:
Assertions are part of a *formal* design-by-contract methodology.
"While the assert construct is not a full-blown design-by-contract facili=
ty,
it can help support an informal design-by-contract style of programming."=
http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html
That supports what I'm saying.
You need to understand design-by-contract and judging by your explanation=
s I
think you don't.
Huh?
Your judgment is awry. I'm explaining how asserts support design by
contract, in conjunction with exceptions and other mechanisms.
Lew wrote:
Calling someone's code "lame" because they programmed against someone
else's future misuse is in itself quite lame.
Giovanni Azua wrote:
No. I said lame because enabling -ea in production would mean that the co=
de
was not tested well and would be quality-wise inadequate to roll into
production. It is in fact not uncommon to see projects rolled into
production with -ea enabled and it is always rooted by concerns about the
lack of quality.
You need evidence to support that those concerns are the reason to
leave assertions enabled.
Enabling assertions in production, while not usually necessary, is
not /prima facie/ evidence of poor code quality.
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.
Lew wrote:
An API writer has the responsibility to enforce proper use of the code
in the public, your disingenuous redefinition of the word "public"
[snip]
"defensive programming" and then disparaging it by arrogating some
special knowledge to oneself puts the cart before the horse. Properly=
-
Giovanni Azua wrote:
Fallacies, you are a notorious master in this area. It is a pity because =
you
keep undermining what would otherwise be very interesting discussions. I
I'm only "undermining" your incorrect statements. I don't agree that
allowing misinformation to stand is synonymous with "interesting".
An API writer does have the responsibility to enforce proper use of
the library. That is not fallacy, that's a well-dcoumented best
practice. Are you seriously suggesting that an API writer not ensure
that the API fulfill its contract? Such a claim would violate a basic
tenet of design-by-contract.
You labeled careful programming "defensive programming" - that was
your label, and then you disparaged it. That is not fallacy. Many
would say that "defensive programming" is a good thing.
You disagree that disparaging "defensive programming" puts the cart
before the horse. Fine, but that doesn't establish that I am in any
way being "notorious". Your use of such a pejorative without
addressing the actual points I made is a logical fallacy in and of
itself.
Giovanni Azua wrote:
don't mind if you don't understand some of the arguments, I am happy to
clarify and help but your rhetorical behavior is far from useful.
Nice piece of arrogant condescension there. Thank you ever so very
much for your oh-so-kind offer. I understood your arguments
perfectly, thank you, as my responses clearly show.
The fact that I disagree with some of your points, and have provided
substantive evidence in support of my claims, does not betray a lack
of understanding of the arguments, at least not on my part. That you
have to resort to such /ad hominem/ rhetoric on your part indicates
that you do not have a strong argument.
So far your only actual refutation of my point is to state that you do
not agree with the material in the Sun document that explains the
correct use of assertions. I think I'll go with Sun and other writers
on that issue. All the rest of your arguments have boiled down to
attaching a favorable label like "design-by-contract" to your
statements, even though those statements directly contradict some of
the principles embodied in that label.
I don't think you even read properly what I wrote, because the design not=
es
explain that PerfectJPattern complies to the JDK design principles explai=
ned
underhttp://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html
Your notes aver that it complies with those standards. It's another
question whether it actually does.
therefore if you are saying that because of what I wrote there you don't
want to use it, it does not really make much sense.
I am saying that because you wrote that assertions should be used to
check public-method arguments, rather than to confirm that such a
check worked, I do not trust your insights. I am saying that because
you wrote that design-by-contract implies that code should not enforce
that contract, I do not trust your insights. In other words, I am
saying that because what you wrote is patently incorrect, I would not
trust your code.
Another very different thing is how I believe validation and assertions
should be used based on what I know about design-by-contract and this was
the main topic being discussed.
You have not really said things that cohere with the principles of
design-by-contract, a concept I understand very well, thank you. What
you have said, that assertions can and should be used to check
argument validity in public methods, is flat-out wrong. You also said
that APIs do not need to perform rigorous checks to enforce their own
contract, but should rely on client programmers being people who
"actually know what they are doing", which is directly antithetical to
the design-by-contract philosophy. I pointed out that design-by-
contract actually calls for APIs to rigorously enforce the promises
that they make; that's little more than a paraphrase of a basic design-
by-contract tenet.
So go ahead and disparage my understanding and make unsupported claims
that you are following principles that your every utterance
contradicts. You have made a couple of extremely inaccurate
characterizations regarding the use of assertions and design-by-
contract that I have refuted with evidence and example. Your
responses attack my comprehension but leave my conclusions
unchallenged by anything stronger than, "I disagree with the experts
you've cited".
Summary:
Assertions are neither intended for nor effective at run-time
validations for public arguments. Their purpose is to prove
invariants.
Design-by-contract calls for an API to enforce its own promises, not
to depend on expertise inaccurately claimed by a proponent and
demanded of putative client programmers. The statements otherwise
contradict the principles of design-by-contract.
Assertions do, as you say, support design-by-contract, but not by
enforcing the contract, rather by proving that enforcement was
successful.
--
Lew