Is initializing a variable to null an antipattern?

Question

Summary

I am looking at a scenario, such as this:

File someFile = null;
try
{
   someFile = File.createTempFile( SOME_PREFIX, SOME_SUFFIX, targetDirectory );
}
catch( IOException e )
{
    throw new SomeException( "Unable to create file for domain specific task", e, SomeExceptionErrorCode.FILE_MANAGEMENT_ERROR );
}
            
try( BufferedOutputStream stream = new BufferedOutputStream( new FileOutputStream( someFile.getAbsolutePath() ) ) )
{
    stream.write( byteData, 0, byteData.length );
    stream.flush();
}
catch( IOException e )
{
    throw new SomeException( "Unable to write domain specific data to domain specific file", e, SomeExceptionErrorCode.FILE_MANAGEMENT_ERROR );
}

For this scenario someFile is initialized with null. My intent is to translate this code into something that follows proper practices.

What I considered

• Simply initializing someFile to null, as shown in the current code snippet. However typically I am avoiding this, so this does not seem satisfactory as of now
• Initializing someFile with e.g. an empty String. This provides a default instance of File of sorts. The problem I see with this is, if this error handling changes in the future, a valid File with nonsense properties could be passed to some other place inside the code.
• Nesting the try-catch blocks. This does work, however for some reason feels bad, especially since both nested blocks catch IOException
• An Optional<File> was also considered, I am however not convinced if every try-catch block where a somewhat complex object is initialized to be used outside that block justifies the use of Optional

Question

Is initializing someFile to null an antipattern? If so, how is a scenario, such as the one posted, handled best?

Answer 1

How about something like this:

public void yourMethod() {
  File file = createFile();
  writeFile(file);
}

private File createFile() {
  try {
    return File.createTempFile(...);
  } catch(...) {
    ...
  }
}

private void writeFile(File file) {
  try(...) {
    ...
  } catch(...) {
    ...
  }
}

So your method stays clean and easy to understand.

EDIT: Or even return an Optional<File> from createFile:

private Optional<File> createFile() {
  try {
    return Optional.of(File.createTempFile(...));
  } catch(...) {
    ...
    return Optional.empty();
  }
}

Then you can use Optional.ifPresent in yourMethod:

public void yourMethod() {
  Optional<File> file = createFile();
  file.ifPresent(value -> writeFile(value));

  // or shorter:
  createFile()
    .ifPresent(this::writeFile);

  // depends on how exactly the methods receive their parameters
}

Answer 2

You can just have

File someFile;

without any explicit assignment.

Java would then normally complain about using that variable before it has a value but the compiler is smart enough to understand that the only way the variable might not have a value is if createTempFile throws an IOException, but since you catch that and then throw again it knows that either the method exits here or someFile has a proper value. Therefore the later usages of someFile.getAbsolutePath() are allowed.

This is cleaner than null because now if you e.g. remove the re-throwing of the exception your code will not longer compile because now the compiler can no longer infer a value will always be assigned. If you init with null and remove the re-throw you will run into an NPE later on.

Optionals are not needed here because the compiler can in this case differentiate between non-initialized value and initialized value.