Re: [Lang] Validate

[Ola Berg <ol...@ports.se>]

> Anyway, the class is hardly tough to write from scratch. (Mine doesn't have
> the fancy array/list checking methods)

Of course. I just want some sort of interface spec to build from, and as I know that you are good at naming things, I thought that you already had coined excellent names for the methods.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>