> 3. Should we establish patterns/methods for validation and better error
> messages in this case?
>
+1 from me too.
One option would be to use bean validation 1.1 on public API methods. If
gradle can inject the validator appropriately, then this would be very
powerful, as gradle could also catch the validation exceptions for better
presentation, translations can be provided, etc.
Or a more "old-skool" approach can be taken. Check for null at the entry
point of the public API, and throw an exception with a friendier
message. In this case it'd be org.gradle.api.tasks.JavaExec.args. If args
is null:
throw new NullPointerException("JavaExec cannot be given null args")
or
throw new IllegalArgumentException("JavaExec cannot be given null args")
I tend to prefer the IllegalArgumentException. In my experience developers
assume that a NullPointerException is only thrown by the JVM and is a sign
that the called code is "bad", whereas an IllegalArgumentException makes it
clear that the API didn't like what the client gave it. Also, you can be
consistent and use IllegalArgumentException for other validation checks
(empty strings, negative values, etc.).
But bean validation 1.1 would be awesome.
Regards
Rob
