Re: Where shoul I throw RuntimeException
Eric Sosman wrote:
Because they [assertions] can be turned off at run-time, leaving you with
no validity-checking at all.
Because, also, that is not the purpose of assertions. Assertions do
not validate, they prove that validation has been done.
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-...
Then you are mistaken, and are completely misusing assertions.
Assertions exist to prove invariants. They are to prove that things
under the API writer's control have been handled, e.g., that an
exception has been thrown to prevent a bad parameter. They do not and
cannot substitute as public variable validators.
Giovanni Azua wrote:
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*. This is because #1
and #2 are the front-line layers that deal with input outside the control of
the application. These are the "filter modules" to the outside world. Using
assertions to deal with Input Validation indeed would be wrong and "wishful
thinking" as Bertrand Meyer calls it.
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.
While the principle is true, that does not change the fact that
assertions are not the right way to validate input. Exceptions
validate, assertions prove.
I just want to stress that there is a difference between Input Validation
and preconditions checks (assertions):
"Object Oriented Software Construction 2nd Edition" Bertrand Meyer, page 345
"Assertions are not an input checking mechanism".
I also included a note on this, see "Defensive Programming Approach":http://perfectjpattern.sourceforge.net/design-notes.html
If that note promotes the same misconception about assertions that you
are spreading here, then you should study up on them and revise your
Read and study Sun's little tutorial on the matter:
Among other things, it teaches:
There are also a few situations where you should not use them:
* Do not use assertions for argument checking in public methods.
Argument checking is typically part of the published specifications
(or contract) of a method, and these specifications must be obeyed
whether assertions are enabled or disabled. Another problem with
using assertions for argument checking is that erroneous arguments
should result in an appropriate runtime exception (such as
IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException).
An assertion failure will not throw an appropriate exception.
* Do not use assertions to do any work that your application
requires for correct operation.
Because assertions may be disabled, programs must not assume that the
boolean expression contained in an assertion will be evaluated.
Violating this rule has dire consequences.
Suggesting otherwise does a huge disservice to anyone who believes