> On 15 Jan 2014, at 8:40, Jochen Theodorou <blackd...@gmx.org> wrote:
>
> Am 13.01.2014 21:04, schrieb Luke Daley:
>>
>> On 13 Jan 2014, at 12:14 pm, Jochen Theodorou <blackd...@gmx.org> wrote:
>>
>>> Luke,
>>>
>>> would you say this is because of the exception style used for not finding
>>> something?
>>
>> There's nothing really stopping us using a custom error message in a
>> getProperty() implementation and perhaps using a custom
>> MissingPropertyException, so I don't think so.
>
> but then I must say I don't get this thread. Sure, if you would do this in
> Java, you would do this different and then get another message. Probably you
> are forced to make one. And if you are forced to make one, you will of course
> ensure a better one.... but here you are practically forced too and blame
> instead the property runtime finding logic. Sure, no bashing. Still I kind of
> don't see the point you are trying to make anymore now.
It's about explicitness and the better error messages that can be provided
through explicitness.
tasks.al
Did that person mistype "all" (i.e. getAll())? Or are they expecting a task to
exist called "al"? The infrastructure can't tell so it just throws MPE with a
generic messages.
tasks.taskWithName("al")
Explicit, so can produce better error.
Our internals HAVE to produce useful error messages. We allow concise forms for
the outer user layer where conciseness trumps (so goes the theory).
We _could_ achieve the same using Groovy internally, but in Java there is
reduced temptation to go the easy way.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
