Perhaps it should be named Validate.argumentNotNull().
Paul
On Monday, October 21, 2002, at 11:23 AM, [EMAIL PROTECTED] wrote:
The code basically replaces:
public void foo(List list) {
if (list == null) {
throw new IllegalArgumentException("The list must not be null");
}
with:
public void foo(List list) {
Validate.isNotNull(arg, "list");
3 lines to 1. Simpler to type. More consistent errors. etc.etc. Sure its not earth shattering, but lang is about simple stuff. Besides lang can use it internally.
Stephen
from: Paul Cantrell <[EMAIL PROTECTED]>
I think the point they're making here (IIRC, this is Josh Bloch
writing) is that assertions are for runtime integrity checks that
should theoretically *never* fail, ever -- things where removing the
check shouldn't change the behavior of the code.
Assertions are essentially runtime unit testing.
The point is that invariants and postconditions are assertions in this
model, but _preconditions_ are not if they depend on values supplied by
the client. The reasons they give are quite reasonable: (1) a module
should do defensive checks whether or not assertions are enabled, and
(2) when a violation of a precondition signals a client programming
error, the exception should be descriptive.
Argument (2) still seems to rule out generic assertion facilities,
since what you really want for preconditions are things like this:
if(hasNullElement(listArg))
throw new IllegalArgumentException("listArg == null");
if(destination == null)
throw new IllegalStateException("provide a destination first");
Again, it doesn't seem like generic assertion utilities have much to
offer here. Generic deep structural check utilities seem more useful,
as in the first example above.
Cheers,
Paul
Here's what the refered document
(http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html) says:
--->8---
* 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.
---8<---
The use of Assert (or whatever) I thought of would be precisely that
illegal use: to faciliate argument checking in public methods (and
throw IAE), in order to enforce object contracts.
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
