> from: Paul Cantrell <[EMAIL PROTECTED]>
> How does Validate.isNotNull() know that it's an
> IllegalArgumentException? That's not the only kind of precondition
> exception (see (2) below).
Actually, I think I throw all of these as IAEs. Being overly clever about the type of
exception just leads to long discussions IMO.
> Perhaps it should be named Validate.argumentNotNull().
Maybe. (In fact I have done this in one of my libraries. The reality is that the state
version, throwing IllegalStateException, is hardly ever used)
Stephen
> 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>
>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
