是否应将java try块的作用域设置得尽可能紧密？

Question

有人告诉我使用Java try-catch机制会有一些开销。因此，尽管有必要将引发检查异常的方法放在try块中以处理可能的异常，但是从性能角度来看，良好的做法是将try块的大小限制为仅包含那些可能引发异常的操作。

我不太确定这是一个明智的结论。

考虑下面处理指定文本文件的函数的两种实现。

即使第一个确实会带来一些不必要的开销，我发现遵循它也要容易得多。仅仅从查看语句来看，确切的例外来自何处尚不清楚，但是注释清楚地表明了哪些语句是负责任的。

第二个比第一个更长且更复杂。特别是，必须对第一个的不错的行读取习惯进行修饰，以使readLine调用适合try块。

在可能在其定义中引发多个异常的函数中，处理异常的最佳实践是什么？

此代码包含try块中的所有处理代码：

void processFile(File f)
{
  try
  {
    // construction of FileReader can throw FileNotFoundException
    BufferedReader in = new BufferedReader(new FileReader(f));

    // call of readLine can throw IOException
    String line;
    while ((line = in.readLine()) != null)
    {
      process(line);
    }
  }
  catch (FileNotFoundException ex)
  {
    handle(ex);
  }
  catch (IOException ex)
  {
    handle(ex);
  }
}

这仅包含在try块中引发异常的方法：

void processFile(File f)
{
  FileReader reader;
  try
  {
    reader = new FileReader(f);
  }
  catch (FileNotFoundException ex)
  {
    handle(ex);
    return;
  }

  BufferedReader in = new BufferedReader(reader);

  String line;
  while (true)
  {
    try
    {
      line = in.readLine();
    }
    catch (IOException ex)
    {
      handle(ex);
      break;
    }

    if (line == null)
    {
      break;
    }

    process(line);
  }
}

Answer 1

这里的基本前提是 错误的：try块的大小不会影响性能。性能实际上受运行时引发异常的影响，而这与try块的大小无关。

但是，将try块保持较小可能会导致更好的程序。

您可能会捕获异常以进行恢复并继续，或者您可能仅捕获异常以将其报告给调用方（或通过某些UI通知给人类）。

在第一种情况下，可以从中恢复的故障通常是非常具体的，这会导致较小的try障碍。

在第二种情况下，捕获到一个异常，以便可以将其包装到另一个异常中并重新抛出或显示给用户，小块try意味着您可以更准确地知道哪个操作失败了，以及在哪个更高级别的上下文中那个电话被打了。这使您可以创建更具体的错误报告。

当然，这些准则还有……例外（抱歉！）。例如，在某些情况下，非常具体的错误报告可能是安全问题。

知道try块对编译后的代码有什么影响可能很有用。它根本不会改变编译的指令！（当然，相应的代码catch块也可以，因为它就像其他任何代码一样。）

阿try块创建与该方法相关联的异常表中的条目。该表具有一系列源指令计数器，异常类型和目标指令。引发异常时，将检查此表以查看是否存在具有匹配类型的条目以及包含引发异常的指令的范围。如果是这样，执行分支到相应的目标号码。

要意识到的重要一点是，除非需要该表，否则不会对其进行查询（并且不会影响运行性能）。（忽略了类加载的一些开销。）