NPE when unboxing a boolean which is null

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

NPE when unboxing a boolean which is null

tugwilson
Marc Palmer has raised an interesting issue (GROOVY-1186) which deserves wider discussion:

def boolean b() {return null}

if (b()).....

This generates an NPE and I really don't think it should

def boolean b = null

if (b)....

is OK

println b shows that b is null

There's a bit of a smell here...

I'm not convinced that a boolean (as opposed to a Boolean) value should ever be null. I think it can be argued that assigning null to a boolean or returning null as a boolean result should cause the value to be converted to false.

Such a change would probably be quite a bit of work. Can you comment on that Blackdrag?

It's trivial to fix the NPE but I think we should consider what semantics we expect when assigning to a boolean.

Comments?


John Wilson
The Wilson Partnership


Reply | Threaded
Open this post in threaded view
|

Re: NPE when unboxing a boolean which is null

Alan Green-2
John Wilson wrote:
> Marc Palmer has raised an interesting issue (GROOVY-1186) which deserves
> wider discussion:
>
> def boolean b() {return null}
>
> if (b()).....
>
> This generates an NPE and I really don't think it should

The NPE is coming from within the call to b(). This code causes the same
error:

def boolean b() {return null}
b()

(I know John knew that, but it took me a few minutes to figure out ;)

Alan.

Reply | Threaded
Open this post in threaded view
|

Re: NPE when unboxing a boolean which is null

Jochen Theodorou
In reply to this post by tugwilson
John Wilson schrieb:

> Marc Palmer has raised an interesting issue (GROOVY-1186) which deserves
> wider discussion:
>
> def boolean b() {return null}
>
> if (b()).....
>
> This generates an NPE and I really don't think it should
>
> def boolean b = null
>
> if (b)....
>
> is OK
>
> println b shows that b is null
>
> There's a bit of a smell here...

you compare here two different things. Even if you declare a boolean you
get a Boolean instead. Because of autoboxing this is no problem. If you
declare a method that returns a boolean, you really get a boolean, not a
Boolean. boolean can't be null.

> I'm not convinced that a boolean (as opposed to a Boolean) value should
> ever be null. I think it can be argued that assigning null to a boolean
> or returning null as a boolean result should cause the value to be
> converted to false.

it's the same for "int i = null"
If we handle boolean as Object it can be null of course ;)

[...]
> It's trivial to fix the NPE but I think we should consider
> what semantics we expect when assigning to a boolean.

1)
I think the following:

def foo(boolean b){
   assert b!= null
   return b
}

boolean bar() {
   return null
}

boolean b = null
assert  b == null
assert  foo(b) == false
assert  bar() == false

2)
another possibility would be to not use boolean for methods and to use
Boolean instead even if boolean was written. but then you can no longer
overwrite methods of a javaclass taking primitve parameters. So this is
no real option.

3)
the next possibility is to not to convert null to false, this means the
call foo(b) will be invalid, as foo(boolean) is incompatible. This also
means a return null in bar will be invalid. And then any non boolean
return in bar should be invalid. But then... we do if(null) or not?
Aren't we breaking our own rules then?

I really think we should go with number 1 here

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: NPE when unboxing a boolean which is null

Alan Green-2
In reply to this post by tugwilson
John Wilson wrote:
> It's trivial to fix the NPE but I think we should consider
> what semantics we expect when assigning to a boolean.

Like Groovy, JDK 1.5 also throws an NPE if there is an attempt to unbox
null. The current behaviour is justifiable, so I don't see any need to
change it, especially in the lead up to 1.0. (Listen to me! I sound like
John Wilson!)

> Comments?

Any solution we adopt for boolean will also have to be applied to the
other primitive types.

Alan.

Reply | Threaded
Open this post in threaded view
|

Re: NPE when unboxing a boolean which is null

tugwilson

On 15 Dec 2005, at 18:42, Alan Green wrote:

> John Wilson wrote:
>> It's trivial to fix the NPE but I think we should consider what  
>> semantics we expect when assigning to a boolean.
>
> Like Groovy, JDK 1.5 also throws an NPE if there is an attempt to  
> unbox null. The current behaviour is justifiable, so I don't see  
> any need to change it, especially in the lead up to 1.0. (Listen to  
> me! I sound like John Wilson!)

:))

except that we do allow unboxing of null Boolean values

Boolean b = null

if (!b) println "hello"

works perfectly well

So the NPE when unboxing a returned value is a bug.
>
>> Comments?
>
> Any solution we adopt for boolean will also have to be applied to  
> the other primitive types.


Not really...

booleans (and Booleans) behave in special and odd ways in Groovy.  
Much to my surprise:

         boolean b = -1

         println b

prints true

so I don't think the behaviour of booleans can or should be imposed  
on other primitives.



John Wilson
The Wilson Partnership
http://www.wilson.co.uk