• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Method argument validation

 
Marco Santinon
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
which is the best way to check if arguments passed to a method are valid?

For example:
public void foo(Bar bar) {
//bar must not be null...
}

1)Using assertions, but assertions must be enabled...
2)Throwing Checked exceptions, but in many cases this could be fatal error, so a checked exception maybe is not the best way...
3)Throwing NullPointerException
4)Throwing IllegalArgumentException

What do you think?


Thanks,
Marco
 
Jan Cumps
Bartender
Posts: 2608
14
C++ Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> 1)Using assertions, but assertions must be enabled...

Assertions are normally not for production code. They are typically disabled when your code runs in the production environment.
They are a very useful mechanism to assess whether your expectations are met during development and test phase. But don't use them as runtime parameter validators.

Regards, Jan
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your method requires a parameter and that parameter is not passed, we can assume that is an error, most probably a programming error. I mean, if the programmer knows the method does not accept a null object as input, why should he/she allow that? The programmer should check for nullability before passing the parameter to the method.

Therefore, my recommendation would be to use an unchecked exception, preferably an standard one, like:

  • IlligalArgumentException: When the parameter VALUE is inappropriate for the method invocation.
  • IllegalStateException: Object state is innapropriate for method invocation.
  • NullPointerException: Parameter value is null where prohibited.
  • IndexOutOfBoundsException: Index parameter value is out of range.
  • ConcurrentModificationException: Concurrent modification of object has been detected where prohibited.
  • UnsupportedOperationException: Object does not support method.

  •  
    Marco Santinon
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks to all!

    I think I'll follow what Edwin suggest.


    Marco
     
    archana kher
    Greenhorn
    Posts: 16
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I follow following rule:
    Checked exception should be used when there is a possibility of recovery after the exception OR any specific action is to be taken after the exception. e.g (some hypothitical example) when one is trying to connect to a database there are number of different possible outcome as a matter of exception. There could be MaxCountReachedException, AccountLockedException, InvalidCredentialException all these exceptions need to take some specific action (possibly show different pages or error messages etc). in such scenario one should use checked exceptions.

    Unchecked excptions are used only for flow. Its sort of aborting a paricular flow. When there is no recovery. E.g above case in case database is down then then there is no point in moving ahead. The outcome is one to stop the application. In such scenarios its gud to throw unchecked exceptions as the exception will be caught at a level which will pull down the application. (well application should be designed appropiately, i.e exceptions are handled at a centralized location). Also as someone mentioned above, unchecked exceptions can also be used as programming errors (special arguments needed, particular state is required etc..)
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic