Fwd: Elvis operator

[Dierk König]

for everybodies information


> Von: Dierk König <dierk.koenig at canoo.com>
> Datum: 17. Juli 2009 09:13:44 GMT+02:00
> An: Alex Buckley <Alex.Buckley at Sun.COM>
> Betreff: Re: Elvis operator
>
>
> Am 16.07.2009 um 23:31 schrieb Alex Buckley:
>>
>> Oh sure. I wasn't suggesting ?. should be called Elvis; quite the
>> opposite. I was seeing that Elvis (?:) is as distinct as can be  
>> from the other operator (?.).
>
> Ok. Good to see we are on the same page here.
> Sorry for misinterpreting your statement.
>
>>
>>>> Turning to more practical matters, do you have a sense of how often
>>>> ?. is used in Groovy code?
>>> There are places, where it is often used, e.g. in GSPs (Groovy  
>>> Server
>>> Pages as used in Grails). This is a special case of access to Maps  
>>> as
>>> the model that is given from the controller to the view is a Map. If
>>> m is a Map, then in Groovy you can refer to the value of key "k"  
>>> in m
>>> as m.k and since that returns null for unknown keys, you often find
>>> Elvis as m.k?.foo() in those usages.
>>
>> Very interesting. This and probably other Groovy idioms that  
>> exploit ?. are exactly why I'm not a fan of it for Java, where the  
>> idioms simply don't apply.
>
> I agree that it is much less useful in Java (this applies to a much  
> bigger extend to the Elvis operator).
>
>>
>>>> Why would anyone dereference with '.' when they could use '?.' ?
>>> because you often want NPE to be thrown for the sake of failing
>>> early. In the example above, you _don't_ write m?.k?.foo() because  
>>> if
>>> m == null you have an ultimate programming error and want NPE to be
>>> thrown.
>>>> If '.' is still commonly used, is Groovy code littered with as many
>>>> == comparisons with null as Java code is?
>>> Not at all. Groovy idiomatic code has very few null checks. The
>>> exceptional case where you need those has to do with the Groovy
>>> truth. You sometimes want to distinguish e.g. between a String being
>>> null and a String being empty.
>>
>> It sounds like an NPE from an "ultimate programming error" is,  
>> somehow, a little more 'acceptable' in Groovy than in Java. I  
>> hesitate to say that, but I am trying to reconcile "very few null  
>> checks" with your clear indication that NPE is sometimes desired.
>
> If you follow the style of programming that no NPE must be thrown  
> whatsoever, then you are right.
> But I find that not practical - neither in Java nor Groovy.
> I don't want NPEs to be thrown because of lacking data, bad user  
> input, missing files, and the likes
> but I _do_ want them to be thrown when they reveal a programming  
> error, i.e. the programmer has
> assumed that this reference cannot be null - but d'oh! - it is.
> This NPE may still be caught at an upper level to not destroy the  
> user experience but the indication
> should be available be it for logging or else. This needs to include  
> the stacktrace.
>
> Using x?.foo() instead means: Yes, I know that x may be null, in  
> which case I'm happy
> to not do foo() at all and return null.
>
> Of course (a like mentioned in other posts) this feature can be  
> carelessly overused. Using
> x?.foo() when trailing code actually relies on foo() being executed  
> would be wrong.
> The Groovy solution to this is preceding your code with the  
> precondition
>    assert x
> that throws an AssertionError if x does not evaluate to true in the  
> sense of the Groovy truth.
> BTW: Groovy asserts are always enabled and give detailed error  
> messages about
> the offending expression and the values of each contained variable.
>
> Fazit: this may well fall into the category of "very useful in  
> Groovy, less so in Java".
>
> all the best
> Dierk