On 3 Mar 2014, at 7:21 pm, Luke Daley <l...@ldaley.com> wrote:
> Hi,
>
> |task blowUp(type: JavaExec) {
> main = 'MainClass'
> classpath = sourceSets.main.runtimeClasspath
> args null
> }|
>
> This produces a less-than-user-friendly NPE:
>
> |Caused by: java.lang.NullPointerException
> at org.gradle.util.GUtil.addToCollection(GUtil.java:135)
> at
> org.gradle.process.internal.JavaExecHandleBuilder.args(JavaExecHandleBuilder.java:179)
> at org.gradle.api.tasks.JavaExec.args(JavaExec.java:261)
> at
> build_7p31187sv6j4incv2nd9fufiog$_run_closure1.doCall(/home/kamils/dev/sandbox/gradle/null_arg/build.gradle:6)|
>
>
> We have a PR that proposes just silently ignoring nulls here and in other
> similar cases: https://github.com/gradle/gradle/pull/251
>
> I'm not sure what we want to do here. Silently ignoring nulls doesn't sit
> well with me. I'd prefer we validate the args early and not allow nulls. We
> don't seem to do this anywhere though that I could find.
>
> So:
>
> 1. Is this current situation good enough?
No
> 2. Should we just silently drop nulls?
No
> 3. Should we establish patterns/methods for validation and better error
> messages in this case?
Yes.
I’d change the decoration and/or DSL layer to deal with this as a cross-cutting
thing. We also want to something very similar for dealing with mutability
during the object’s lifecycle.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
