将变量初始化为空是反模式吗？

Question

总结

我正在看一个场景，例如：

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 );
}

对于这种情况，someFile 被初始化为 null。我的目的是将这段代码翻译成遵循正确做法的东西。

我的考虑

• 只需将someFile初始化为null即可，如当前代码sn-p所示。但是通常我会避免这种情况，所以到目前为止这似乎并不令人满意
• 用一个空的String例如初始化someFile。这提供了File 的默认实例。我看到的问题是，如果这个错误处理在未来发生变化，一个带有废话属性的有效File 可能会被传递到代码中的其他地方。
• 嵌套try-catch 块。这确实有效，但是出于某种原因感觉很糟糕，尤其是因为两个嵌套块都捕获了IOException
• 还考虑了一个Optional<File>，但是我不相信如果每个try-catch块初始化了一个有点复杂的对象以在该块之外使用，是否证明使用Optional是合理的

问题

将someFile 初始化为null 是一种反模式吗？如果是这样，如何处理最好的场景，例如发布的场景？

Answer 1

这样的事情怎么样：

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

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

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

因此您的方法保持简洁且易于理解。

编辑：甚至从createFile返回Optional<File>：

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

那么你可以在yourMethod中使用Optional.ifPresent：

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

你可以拥有

File someFile;

没有任何显式赋值。

Java 通常会在该变量有值之前抱怨使用该变量，但编译器足够聪明，可以理解该变量可能没有值的唯一方法是 createTempFile 抛出 IOException，但既然你抓住它，然后再次throw 它知道该方法在这里退出或someFile 具有正确的值。因此，someFile.getAbsolutePath() 的后续用法是允许的。

这比null 更干净，因为现在如果你例如删除重新抛出的异常，您的代码将不再编译，因为现在编译器无法再推断将始终分配的值。如果您使用 null 初始化并删除重新抛出，您稍后将遇到 NPE。

这里不需要选项，因为在这种情况下编译器可以区分非初始化值和初始化值。