Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

handling a null input argument in a method which returns an int

 
sridhar signon
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


If fdn is null, what is the best practice
-throw an runtime exception
-check for null, and return 0
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It really depends what your requirements are.

If 0 is a value that could be a valid value that comes from the computation, it is probably a bad approach.

If you resign from throwing an exception, agree on an error value and document it. If you do use Exceptions, document the exeption as being thrown when there is no value available.
 
John Bengler
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sridhar,

I would say that depends. If you're able to return a value that makes sense then return it, if not throw e.g. an IllegalArgumentException..

If there is any doubt I would prefer to throw an error, according to the crash early principle, which says that in case of an error an application should crash as early as possible.


John
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with John Bengler, but since there already is a built-in Exception specially designed for that occurrence, best to use that class.
 
sridhar signon
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will use the IllegalArgumentException and document it in the method comments. The return value of 0 may not make sense in my case. Thanks to you all.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is the argument *likely* to be null? Or is it a programming error if it's null?
 
Suren Singh
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose your code snippet looks like

public void doSomeStuff(String str){

// here your are invoking some methods on other objects

otherObject.somemethod();


}

Should we check for non nullness of otherObject as well , if its null it will throw NPE.

What does the best practice says about validatin an object before invoking any methods on them .

 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should have checked otherObject is not null earlier. If it is a field, it ought to be initialised in the constructor. If it is set by a set method, that set method ought to check for nullity and throw a NullPointerException if null is passed. As John Bengler says, "crash early".
 
sridhar signon
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Is the argument *likely* to be null? Or is it a programming error if it's null?

It is a programming error if it's null. So thats why I intend to throw IllegalArgumentException in case of a null.

 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Correct to throw an Exception, but I still think NullPointerException would be better than IllegalArgumentException.ah
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm... an IAE is more descriptive, though. Not sure what I'd do.
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to Joshua Bloch it is usual to use an NPE. In fact this situation fits the description of IAE and NPE.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, I know what Bloch says. In situations like this, though, I'd rather just throw something w/ as much information as possible. I guess the message could be used to clarify.

For method pre-conditions like this I either use something like SpringContracts or I have an application-specific pre-condition exception anyway.

If it's a *programming* error this could be an assert, too.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic