Skip to main content

Bug in Boolean.parseBoolean?

5 replies [Last post]
Joined: 2006-10-30

next code is supposed to print "1", "2","3" to stdout (at least intution says so) :

}catch(Exception e){
}catch(Exception e){
}catch(Exception e){

But it actually returns "1","2", since the Boolean API arbitrarily decides (with no further explanation) that a null maps to false, not raising any parsing exception. From my point of view this is a big error and breaks the "simetry" with the rest of the parse* functions.

It promotes buggy code. For example next code will produce random errors if other piece of software forgets to send the proper HTTP parameters.

boolean bFlagActive = Boolean.parseBoolean(request.getParameter("parameter1"));
boolean bFlagNoActive = Boolean.parseBoolean(request.getParameter("parameter2"));

Certainly, it's always possible to check for null values but people used to other similar APIs (parseInt, LarseLong,...) will expect an exception to be raised and most probably will not check for it. And what's even worse, since ParseException derives from java.lang.Exception java editors (Netbeans/Eclipse) will find it difficult to notify when the catch exception is needed and when it's not (providing a hint that something doesn't work as expected). Even unit-tests will randomly fail 50% of times!.

Guess it ought to be deprecated in favor of something more intuitive and less risky. For example:

parseBoolean(String booleanRepresentation, Boolean defaultValue);

so that it will return the defaultValue in case (booleanRepresentation==null && defaultValue!=null) or raise an new exception in case (booleanRepresentation==null && defaultValue==null).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-10-30

Just browsing some random code examples( I found most of of them can be affected by this "bug" in the API design and unentionally returning a "false" false.

My two cents!


Joined: 2008-02-12

Well I didn't read the full contents of message but:

I can feel you, when parsing primitive types with final class and there is something deviant. This can mess your procedure.

Boolean has two values 'true' or 'false'. If and only if string is "true" the value is 'true' then everything else is 'false'. In my opinion that is sensible !

And happy new year :)

Message was edited by: jaded83

Joined: 2008-12-30

Sun API says:
for Boolean.parseBoolean(String s)
"Parses the string argument as a boolean. The boolean returned represents the value true if the string argument is not null and is equal, ignoring case, to the string "true" "

It's clear: in all other cases it'll return false, since no exception are declared to be thrown.
The parseInt and parsLong methods, instead, throw a NumberFormatException. The choice of throwing an exception in case of null argoment for the numeric types is that those methods must return a NUMBER (int or float), so if they didn't throw an Exception how would a programmer realize that the he parsed an invalid string?

The parseBoolean, instead is governed by a totally different philosophy: it must catch only "true" strings. So it would have been called isBooleanTrue().
In effect the behaviour could be:
"Parses the string argument as a boolean. The boolean returned represents the value false if the string argument is not null and is equal, ignoring case, to the string "false" "
The exact contrary. And I think this is no logical.

It resembles the C approach, where boolean don't even exist and every non-zero value is considered true. I disagree with Sun

I also noticed that parseInt is (probably) present since Java 1.0, althought parseBoolean() was fisrt introduced in JDK 1.5 - I guess they were written by two different persons...

Joined: 2006-10-30

Certainly, returning a defined value (true or false) from an undefined value (null) doesn't make any sense. That would mean calculating the concrete value of x resolving the equation x=f(y) where y is unknown (just a drunk man can solve such equation).

Does anybody knows where to post this bug to Sun -appart from this forum-?

Thx again for your comments!

Joined: 2005-11-01

You can write your own parseBoolean and call that.
I don't think how these methods handle null is much of an argument for symmetry.
NPE isn't a gracefully handling of user input value in any case.

could be something like
getBoolean(request, "parameter1")
which throws an IllegalArgumentException("parameter1" + " must be set.");
IMHO This would be clearer than an NPE.