Basic design decision...
Do we :
1) only deal with IAEs
2) put IAEs and IStateE (ISEs) in the same class, thus prefixing each method by
argument and stateCheck
3) Name the classes ValidateArgument and ValidateState.
(I think I favour #3)
For your interface, I would name the type method isInstanceOf, instead of isOfType.
Yes, to basic String and Collection methods. No, to the number ones (isTrue(i > 0) is
just as easy).
Yes, to having two versions of each method, one with a message and one without. The
one without could create a sensible error message.
Are you volunteering to write this ;=) ??
Stephen
> from: Ola Berg <[EMAIL PROTECTED]>
> Initial interface spec:
>
> //contains static utility methods that throws IAE,
> class Validate
>
> //throws if false: general utility
> isTrue( boolean)
>
> //most common, most other methods calls this as well before other checks
> notNull( Object)
>
> //throws if Object can't be assigned to a variable of type
> isOfType( Object, Class type)
>
> //throws if the array is empty
> notEmpty( Object[])
>
> //throws if the array contains null elements
> noNullElements( Object [])
>
> end class Validate
>
> ---
> Other possible methods
>
> * relevant checks for Strings and other common classes in java.lang (and primitives)
>such as
> notEmpty( String s)
> isPositive( int i)
> isPositive( Number) //is Number good for this or do we need
>
> * relevant checks for Collection classes (so that arrays and collections behaves the
>same) such as
> notEmpty( Collection c)
> noNullElements( Collection c)
>
> * relevant checks for other common java.util classes too (Date etc)
>
> * relevant checks for other common java classes (io and net, few javaprogs manages
>without lang, util, io and net)
>
> ----
>
> Personally, I think that the two last points are overkill, but they raises a
>question: should we have some kind of (naming/design) pattern for creating validation
>utilities for other type, in order to promote consistency?
> ----
>
> Important issue: Exception messages
>
> Should each method have a String argument containing the messages? Or should each
>method exist in two versions, one that throws a default message and one that can take
>a provided message:
>
> public static void noNullElements( Object[] array){
> ....
> }
>
> public static void noNullElements( Object[] array, String message){
> ....
> }
>
>
> What do you think?
>
> /O
>
>
>
>
> --
> 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>
