Menu
Are there are any performance cost by creating, throwing and catching exceptions in Java?
I am planing to add 'exception driven development' into a larger project. I would like to design my own exceptions and include them into my methods, forcing developers to catch and do appropriate work.
For example, if you have a method to get a user from the database based on a name.
public User getUser(String name);
However, it is possible that the user might be null and it is common to forget to check this before using a User's public method.
User user = getUser("adam");
int age = user.getAge();
which would result in NullPointerException and a crash. However, if I made a check, before returning the user-object, if its null and throw an 'UserIsNullException':
public User getUser(String name) throws UserIsNullException;
I force the implementor to think and act:
try {
User user = getUser("adam");
int age = user.getAge();
}catch( UserIsNullException e) {
}
It makes the code much safer for unexpected crashes and eliminates more bugs. Let say the website has hundreds of visitors per hour and this design pattern is used pretty much everywhere.
How would such a design approach effect performance? Do the benefits out-weigh the cost or is it just plain bad coding?
Thanks for any help!
UPDATE! To be clear, my attention is not wrap a NullPointerException, as my example might suggest. The goal is to force the implementer to write a try/catch, saving the head ache of a real crash since a:
user == null
was forgotten. The question concerns comparing these two design models:
int age;
try {
User user = getUser("adam");
age = user.getAge();
}catch( UserIsNullException e) {
age = 0;
}
versus:
int age;
User user = getUser("adam");
if( user != null ) {
age = user.getAge();
} else {
age = 0;
}
301
In Java, exceptions are generally considered expensive and shouldn't be used for flow control.
In general, wrapping your Java code with try/catch blocks doesn't have a significant performance impact on your applications. Only when exceptions actually occur is there a negative performance impact, which is due to the lookup the JVM must perform to locate the proper handler for the exception.
So we clearly see there is an extra cost for exception handling that increases the deeper the stack trace goes. This is because when an exception is thrown the runtime needs to search up the stack until it hits a method than can handle it. The further it has to look up the stack, the more work it has to do.
Altogether, the most common way is to use @ExceptionHandler on methods of @ControllerAdvice classes so that the exception handling will be applied globally or to a subset of controllers. ControllerAdvice is an annotation introduced in Spring 3.2, and as the name suggests, is “Advice” for multiple controllers.
There is a performance penalty to throwing an exception, but that's usually acceptable because the exception handling code only executes in exceptional cases. If you start using exceptions for flow control, you're turning the usual case around and making them expected behavior. I'd strongly recommend against it.
104
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
