I seem to recall that Sun says something like this in some document, someplace. But many developers disagree, and in fact, many would say that using assertions as a way to test the arguments of public methods makes a lot of sense.
Using assertions to check internal consistency seems to me to be appropriate, and wise, in any code, public or not. Using assertions to check the arguments of public methods may or may not be appropriate; I think it depends what sort of software you are working on.
If you are working on a library that other people will get and will probably run in release (i.e. no assertions) mode, then using assertions to check the arguments of public methods might be inappropriate. That is because the client running your library may have assertions switched off, and hence might fail to get the feedback that the assertion would have given. They may then get some catastrophic failure in your code, which they may blame on you, not realising that in fact they supplied a bad argument. When working on such a library, I think that it is appropriate to reward bad arguments to a public method with a java.lang.IllegalArgumentException.
On the other hand, if you are working on a reasonably self-contained piece of software, under your own control, then using assertions to check arguments seems fine to me (I do it plenty). The advantage is that all the argument-checking code can be excluded automatically from released code, simply by turning off assertions. This will give released code a performance advantage, while allowing debug sessions to benefit from maximum checking. [ July 27, 2006: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
I see no reason why one should not use assertions in a public method, personally.
In my opinion, assertions should NOT be used to check method parameters in a public method, however. Instead, you should throw IllegalArgumentException, or some other appropriate exception, allowing the client to catch and recover from those exceptions. You COULD use assertions to check parameters of private methods, however, because it should always be YOUR code that invokes those methods, so you could reasonably expect that the methods are being used correctly. Furthermore, AFTER you do your parameter checks in a public method, there is no reason why you couldn't use assert to perform pre-condition and post-condition checks, or other class-invarients checks.
A final note: for any code that will be distributed to clients, it is possible that the clients will have assertions turned off. This is generally okay, because assertions should generally never fail (if you expect a high frequency of failures, then you are not using assert correctly, or else you have a LOT of bugs in your code). However, sometimes it is more appropriate to replace an assert with an if(condition) throw new AssertionError(); if you want to make sure a certain assertion gets made even if the client disables assertions. Fail-fast behavior will help you debug problems that occured on your client's machines, as well as bugs that occured on yours.
Originally posted by Arun Prasath AV: why using assertion in public method is inappropriate?
Using assertion in any method is inappropriate, but you likely won't read that on Sun's website (or any others with a vested interest).
If your method has a pre-condition, enforce it. It would be nice to enforce it within the language itself, but Java does not permit this (no matter what - there is mathematical proof of this for all cases).
Assertions take away two things: 1) Definite assignment semantics (very few people understand and/or use it appropriately anyway - to demonstrate trivially, ever wondered why a formal FP language such as Haskell *must* have 'else' for any 'if')? 2) The ability to turn it off - one or two steps of deductive logic can ascertain the silliness of this.