Where shoul I throw RuntimeException

[Lew]

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;

Besides, assertions were introduced in Java as an "informal" design by contract:

Assertions are part of a *formal* design-by-contract methodology.

"While the assert construct is not a full-blown design-by-contract facility,
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 explanations 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.

No. I said lame because enabling -ea in production would mean that the code
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.

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-
[snip]

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.

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 notes
explain that PerfectJPattern complies to the JDK design principles explained
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]

[...]
In general I disagree with this rule "do not use assertions to check the
parameters of a public method":

     That was Giovanni Azua's statement, not mine.

That is why I wrote in a follow-up:

Side note: in my earlier post the single-">" quote are from
Giovanni Azua, not Eric Sosman unless specified to be from
the Sun document on assertions.

I apologize for the misattribution. I trusted the automatic quoting
mechanism and forgot to double-check it.

Of course you would not have said anything so fundamentally mistaken.

 

[Giovanni Azua]

Checking array indices for validity is "worthless?"

Using defensive validation I respectfully disagree with you, in my view it
is not more optimal than using assertions or design-by-contract. The
defensive validation alternative is very pragmatic but comes at a cost:
performance.

Testing can prove code to be bug-free?

Indeed it can't, but neither can doing input validation in every API layer
nor defensive programming. There is no silver bullet solution for this
problem but correct use of either approach will minimize the risk.

 

[Giovanni Azua]

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

Assertions are part of a *formal* design-by-contract
methodology.

Not true, design-by-contract has e.g. subcontracting inheritance semantics,
and assertions do not
http://archive.eiffel.com/doc/manuals/technology/contract/page.html see "8-
Contracts and Inheritance". If you knew design-by-contract you would also
know that. This is why I said it is informal support quoted directly from
the document above "While the assert construct is not a full-blown
design-by-contract facility, it can help support an informal
design-by-contract style of programming".

Huh?

Indeed you don't.

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. null value then you roll into production with assertions disabled
because the assertion check is not necessary in production e.g. some
filtering API layer way above may ensure this.

I'm only "undermining" your incorrect statements. I don't agree that
allowing misinformation to stand is synonymous with "interesting".

No, you are only deceiving big time.

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-Orient...=sr_1_1?ie=UTF8&s=books&qid=1242945595&sr=8-1

 

[Giovanni Azua]

Also, if assertions are misused as validators, it's quite likely

I never suggested this, in fact, the first thing I did was to break down the
cases: real input validation vs. preconditions check

that you'll need to enable assertions in class BugFree in order to
catch misuses originating in class BugRidden. I don't see how this
would tag BugFree with the "lame" label

Can't happen because you tested BugRidden too, remember? unless we are
talking meta-programing here, are we?

 

[Seamus MacRae]

Hi Eric,

because ... ?

Because they [assertions] can be turned off at run-time, leaving you with
no validity-checking at all.

In general I disagree with this rule "do not use assertions to check the
parameters of a public method":
http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html#usage-conditions

These would be the possible scenarios interacting with an API:

1-. Human to software interaction: end-user enters data
2-. External system to software interaction: binary interoperability of
separate components e.g. MOM
3-. Software to software interaction: a library e.g. JDK is being used to
develop some application

In cases #1 and #2 it is necessary to use exceptions e.g.
IllegalArgumentException to deal with *Input Validation*.

I disagree. Input validation (of interactive applications) should occur
using conditionals and divergent behavior in the presentation layer. For
instance if (i > 99) JOptionPane.blahblahblah("Size is too big; maximum
99")etc.etc.etc.return; else
somethingInBusinessLayer.doSomethingWith(i); (maybe make it localizable
by using message bundle).

IllegalArgumentException, and other RuntimeExceptions, should be thrown
by your public methods when there's a bug in the code, generally
indicated by a precondition violated. If the promise can't be kept
(postcondition violated) despite preconditions being met throw a checked
exception (IOException for example). Asserts can be used in private
methods to check preconditions, and throughout to check invariants and,
before returning but after any checked exception throws haven't
happened, postconditions.

DAL methods that get data from the outside world also need to deal with
errors or invalid data. Files not found or in an unexpected format, for
instance. When the DAL fails that's generally a postcondition failure;
IOException is a good generic exception to throw. It could be a
precondition failure (wrong file name, say) but if the file name came
from other external data, I say that's still in IOException territory.

The general pattern should be:

If the error is in code and the preconditions were met or the method is
private to my code, I should use an assert.

If the error is in calling code and the method is part of a public API,
I should use a RuntimeException. If it's a precondition violation and an
argument is bad, IllegalArgumentException is good. If it's a
precondition violation and the precondition violated has to do with the
object's internal state rather than an argument, IllegalStateException
is good.

If the error is in user input, the user interface should be used, rather
than exceptions, to handle it, and the bad input should never reach the
business layer. (If it ever does, the business layer should throw
IllegalArgumentException or similar as per the above.)

If the error is in other external-source data, IOException or a similar
checked exception should be used. If there are errors in taking actions
that involve the filesystem, network, interprocess communications,
databases, or similarly, a checked exception should be used. The DAL can
try to work around the problem but should throw a checked exception up
to the business layer if it can't make headway with a request. The base
type of these last exceptions should probably be your own
general-purpose DAL exception type or else IOException. Catch something
else and rethrow using a constructor that takes a "cause" if need be.

At least, this is my opinion, as a longtime Java developer.

Using assertions to deal with Input Validation indeed would be wrong
and "wishful thinking" as Bertrand Meyer calls it.

Agreed here.

Now point #3 is the case of application interacting with a library e.g. JDK.
There is no external wrong input to deal with but only programming errors, a
precondition violation is a programming error in the client of the routine
or class. Programming errors must be discovered during testing and debugging
cycles when assertions are enabled and not in production.

This is debatable. The currently generally used best practices use
RuntimeException rather than assertions, but this tradition was
established before Java had assertions. The case could be made, but then
it would make sense to replace most or all RuntimeExceptions (and
Errors) with asserts and just have AssertionError, VMError, OOME, and
(checked) Exception. Well, were it not for backwards compatibility.

 

[Seamus MacRae]

Hello Eric,

Thought experiment: Should the array-accessing operation treat
the index value as an input to be validated, or as a precondition
whose validity has been established during the testing phase and
need not be checked thereafter? That is, would you be in favor of
checking indices with an assert-like mechanism that could be turned
off once the code had passed enough tests? Surely it's a programming
error if the code generates an invalid index; should the detection
of that error be suppressable?

To be honest I'd personally prefer to spare all the worthless and expensive
validations and hence the [substantial?] performance overhead resulting from
this Defensive Programming approach when I know my code is throughly tested.
I really prefer here the C++ way, they assume you know what you are doing.

The C++ way leads to buffer overflow vulnerabilities and thence to madness.

When security is at stake, un-disablable runtime checks are desired. So,
RuntimeException rather than assert there for sure.

Also, premature optimization is the root of all evil. You'd really only
want to be able to turn off validations in innermost loops and
oft-called methods anyway (and still validate everything just before
going into the loops). Even validation in innermost loops is probably
not an issue. If the code has array accesses, is thoroughly tested, and
is bug-free, for example, the bounds check should never fire, and modern
CPUs typically do pipelining and branch prediction, so ...

 

[Lew]

That must be why it is the standard in the JDK, see e.g. [sic] this same method
declares throws IllegalArgumentException and IllegalStateException both
RuntimeExceptions
http://java.sun.com/javaee/5/docs/a....html#find(java.lang.Class, java.lang.Object)

That method does not declare runtime exceptions.

Note that the exceptions are Javadoced, as I said is wise, and not in the
signature. Compare with
<http://java.sun.com/javase/6/docs/api/java/io/File.html#createNewFile()>
which declares one exception and Javadocs two, the first being checked and the
other not.

 

[Lew]

Eric Sosman wrote

Can't happen because you tested BugRidden too, remember? unless we are
talking meta-programing here, are we?

Again, every client for all time must be bug free to obviate the need for the
API to validate, and there's no way to guarantee that. The purpose of
guarding input is to validate inputs from future unpredictable sources. In
order for the API, and that means any public or protected method of a public
class, to adhere to the principles of design-by-contract, that API must
enforce the contract.

 

[Seamus MacRae]

No, you are only deceiving big time.

Ah. I see that "Lew" has managed to turn yet another thread into an
incipient flamewar. Not only has be called Giovanni a liar twice (in
<[email protected]>,
using the terms "disingenuous" and "misrepresenting"), but now Giovanni
has been sufficiently provoked to turn right around and call "Lew" one.

That other thread started flaming big-time after, and only after, "Lew"
began to participate heavily, too; until then it had been only
moderately uncivil here and there and it has maybe calmed back down some
since he left it.

 

[Seamus MacRae]

[...]
In general I disagree with this rule "do not use assertions to check the
parameters of a public method":

<http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html>

That was Giovanni Azua's statement, not mine.

That is why I wrote in a follow-up:

Side note: in my earlier post the single-">" quote are from
Giovanni Azua, not Eric Sosman unless specified to be from
the Sun document on assertions.

I apologize for the misattribution. I trusted the automatic quoting
mechanism and forgot to double-check it.

Perhaps instead of manually rearranging the attributions like you often
do (but sometimes forget to do), you should let your newsreader do it?

In the earlier post your newsreader would've made

insert your text here

> Stuff Giovanni wrote
> Stuff Giovanni wrote
> Stuff Giovanni wrote

more comments here.

You went to do your usual edits to change to


inserted text

> Stuff Giovanni wrote
> Stuff Giovanni wrote
> Stuff Giovanni wrote

and forgot to insert the "Giovanni wrote:".

Most of us just let the newsreader attribute as it usually does. I don't
see the point in rearranging things, except maybe if far down a long
post you have a deeply nested quoted bit you don't want to trim and it's
not the case that it's the same two people alternating at least to that
depth. And then it might be better to *copy* some of the attributions
from the top, rather than *move* them.

 

[Lew]

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

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.

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

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:

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-Orient...=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]

Using defensive validation I respectfully disagree with you, in my view it
is not more optimal than using assertions or design-by-contract. The

Design-by-contract requires what you call "defensive validation".

defensive validation alternative is very pragmatic but comes at a cost:
performance.

Performance at the expense of correctness is a pig in a poke.

Indeed it can't, but neither can doing input validation in every API layer
nor defensive programming. There is no silver bullet solution for this
problem but correct use of either approach will minimize the risk.

Unfortunately, what you recommend, Giovanni, is incorrect use of DbC.

 

[Seamus MacRae]

And yet I have been able to support my claims with direct evidence
instead of /ad hominem/ attacks, even using your own authorities.

Actually, you have supported your claims with direct evidence *as well
as* /ad hominem/ attacks. Better than just the latter, at least, though
not better than just the former.

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.

Worth noting is that if you detect the "null" and throw an exception
like IllegalArgumentException, the code will still bomb.

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.

I don't believe he ever claimed that *disabled* assertions can do that.
I believe he claimed that code still under development could use
*enabled* assertions instead of RuntimeExceptions to do that, and I
myself note that production code will still bomb, whether it catches a
RuntimeException in a precondition check, an AssertionError (asserts
still on), or a RuntimeException from bounds checking, null
dereferencing, or other errors.

In Java, disabled assertions plus lack of precondition checking
exception throwing leads to one bad result: some bugs that would have
caused immediate crash with a RuntimeException stack trace now cause
logic errors that may corrupt data or cause other trouble before people
realize something is wrong.

This is my reason for preferring RuntimeException, and because stack
traces may be more useful to the developers (leading closer to real
source of error sometimes).

In C or a similar language, validation in production code is truly
crucial: an error is likely to create vulnerabilities like buffer
overruns, and it is *very* easy for errors to quietly corrupt data
rather than crash overtly and immediately. It's a shame C's the language
with the least support for this: no exceptions, little else.

C also has a difference wrt asserts. If a library is compiled with
asserts off, you compile your code with asserts on, and you test your
code, the asserts in your code are on but any in the library are off.
The library asserts therefore can't catch you violating library function
preconditions.

Java asserts are turned on in the JVM, and the system classloader then
doesn't strip assertion code from loaded classes. So asserts still have
zero runtime memory or CPU penalty when disabled (except for a slight
loss of speed during classloading, which is not normally going to occur
repeatedly in a performance hotspot). The thing is, library class
asserts will be enabled too if the system classloader loads them and the
JVM is running with asserts enabled, not just asserts in your own code.
So library asserts COULD guard against precondition violations in
library methods during your testing.

But I still favor RuntimeException, both because it'll work with older
Javas and because when the code is in production and if asserts are then
off sometimes a quick crash will take the place of silent data
corruption or wrong answers that way.

Now do try to argue on the basis of logic and evidence instead of
name-calling henceforth, hm?

Words for the wise. I suggest you both follow that advice.

 

[Eric Sosman]

I never suggested this, in fact, the first thing I did was to break down the
cases: real input validation vs. preconditions check

Can't happen because you tested BugRidden too, remember? unless we are
talking meta-programing here, are we?

Ah. So all we need is a suitable predicate, like

assert
callerAndCallersCallersAllTheWayUpTheStackHaveBeenThoroughlyTestedAndTheTestsWereComprehensiveAndTheResultsWereProperlyScrutinizedAndEverythingIsCopaceticAndGodsInHisHeavenAllsRightWithTheWorldOhAndByTheWayItsThreadSafeToo()
: "Danger, Will Robinson!";

The implementation of the predicate is left as an exercise.
Don't forget to test it ...

 

[Eric Sosman]

[...]
In general I disagree with this rule "do not use assertions to check the
parameters of a public method":

<http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html>

That was Giovanni Azua's statement, not mine.

That is why I wrote in a follow-up:

Side note: in my earlier post the single-">" quote are from
Giovanni Azua, not Eric Sosman unless specified to be from
the Sun document on assertions.

I apologize for the misattribution. I trusted the automatic quoting
mechanism and forgot to double-check it.

Of course you would not have said anything so fundamentally mistaken.

Seems to me, Lew, that you and I have disagreed on a
few occasions. Glad to hear they weren't fundamental ...

(More than forty years since I was first paid to write
code, and I *still* make mistakes. My longevity and success
are due mostly to the fact that I tend not to repeat them, or
at any rate not often. But the population of potential mistakes
is quite large, and I doubt I'll live long enough to make all
of them and have the opportunity to say "Never again!" for
every single one. Ars longa, vita brevis.)

 

[Lew]

Seems to me, Lew, that you and I have disagreed on a
few occasions. Glad to hear they weren't fundamental ...

Then I must have been wrong.

All kidding aside, encountering intelligent, reasoned and well-argued
disagreement is one of the most powerful ways to learn.

Where I have worked, while they have formal code reviews, in the press of
deadlines they tend to happen after code has been released to a build. I am
in the habit of seeking those fellow developers who most consistently disagree
with my programming style and ideas and simultaneously provide the most
compelling arguments for their positions, and showing them my code in its
early stages. One of two things happen - I modify my code in the direction
they suggest or I don't, being more certain of my approach than ever in the
latter case. The former happens somewhat more often.

Lately I've noticed that those same individuals that I seek for reasoned
opposition have the same habit. Occasionally they come to me for disagreement
also.

I could generalize and suggest that those practitioners who seek truth, even
at the expense of having to give up a cherished idea sometimes, benefit royally.

 

[Seamus MacRae]

[...]
In general I disagree with this rule "do not use assertions to
check the
parameters of a public method":

<http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html>

That was Giovanni Azua's statement, not mine.

That is why I wrote in a follow-up:

Side note: in my earlier post the single-">" quote are from
Giovanni Azua, not Eric Sosman unless specified to be from
the Sun document on assertions.

I apologize for the misattribution. I trusted the automatic quoting
mechanism and forgot to double-check it.

Of course you would not have said anything so fundamentally mistaken.

Seems to me, Lew, that you and I have disagreed on a
few occasions. Glad to hear they weren't fundamental ...

(More than forty years since I was first paid to write
code, and I *still* make mistakes. My longevity and success
are due mostly to the fact that I tend not to repeat them, or
at any rate not often. But the population of potential mistakes
is quite large, and I doubt I'll live long enough to make all
of them and have the opportunity to say "Never again!" for
every single one. Ars longa, vita brevis.)

Large butt, short life???

 

[Seamus MacRae]

Then I must have been wrong.

All kidding aside, encountering intelligent, reasoned and well-argued
disagreement is one of the most powerful ways to learn.

Where I have worked, while they have formal code reviews, in the press
of deadlines they tend to happen after code has been released to a
build. I am in the habit of seeking those fellow developers who most
consistently disagree with my programming style and ideas and
simultaneously provide the most compelling arguments for their
positions, and showing them my code in its early stages. One of two
things happen - I modify my code in the direction they suggest or I
don't, being more certain of my approach than ever in the latter case.
The former happens somewhat more often.

Lately I've noticed that those same individuals that I seek for reasoned
opposition have the same habit. Occasionally they come to me for
disagreement also.

Do you ask them whether they want five minutes or the full half hour?

 

[John B. Matthews]

Ars longa, vita brevis

<http://en.wikipedia.org/wiki/Ars_longa,_vita_brevis>