Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Try. Finally. If. Not. Null.

DZone's Guide to

Try. Finally. If. Not. Null.

Lots of pre-Java 7 code reviews reveal a "try/finally" mistake. Here's a look at dealing with non-AutoCloseable resoruces, and how to open and close correctly.

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

There is a very typical mistake in pre-Java7 "try/finally" scenario, which I keep seeing in so many code reviews. I just have to write about it. Java7 introduced a solution, but it doesn't cover all situations. Sometimes we need to deal with non- AutoCloseable resources. Let's open and close them correctly, please.

This is how it looks (assuming we are in Java 6):

InputStream input = null;
try {
  input = url.openStream();
  // reads the stream, throws IOException
} catch (IOException ex) {
  throw new RuntimeException(ex);
} finally {
  if (input != null) {
    input.close();
  }
}

I already wrote about null and its evil nature. Here it comes again. If you just follow the ruleof "not using NULL anywhere ever," this code would need an immediate refactoring. Its correct version will look like this:

final InputStream input = url.openStream();
try {
  // reads the stream, throws IOException
} catch (IOException ex) {
  throw new RuntimeException(ex);
} finally {
  input.close();
}

There is no null anymore and it's very clean. Isn't it?

There are situations when opening the resource itself throws IOExceptionand we can't put it outside of try/catch. In that case, we have to have two try/catch blocks:

final InputStream input;
try {
  input = url.openStream();
} catch (IOException ex) {
  throw new RuntimeException(ex);
}
try {
  // reads the stream, throws IOException
} catch (IOException ex) {
  throw new RuntimeException(ex);
} finally {
  input.close();
}

But there should be no null, never!

The presence of null in Java code is a clear indicator of code smell. Something is not right if you have to use null. The only place where the presence of null is justified is where we're using third-party APIs or JDK. They may return null sometimes because... well, their design is bad. We have no other option but to do if(x==null). But that's it. No other places are good for null.

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:
java ,design pattens

Published at DZone with permission of Yegor Bugayenko, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}