java try块应该尽可能紧密地限定范围吗？

Question

我被告知使用Java try-catch机制会有一些开销.因此,虽然有必要在try块中放置抛出checked异常的方法来处理可能的异常,但是在性能方面优化的做法是限制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块的大小无关.

但是,保持较小的试块可以带来更好的程序.

您可能会捕获恢复和继续的异常,或者您可能只是将它们报告给调用者(或通过某些UI向人类报告).

在第一种情况下,您可以从中恢复的故障通常非常具体,这会导致更小的try块.

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

当然,这些指南有......例外(抱歉!).例如,在某些情况下,非常具体的错误报告可能是安全问题.

了解try块对编译代码的影响可能很有用.它根本不会改变编译指令!(当然,相应的catch块也可以,因为它就像任何其他代码一样.)

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

要实现的重要一点是,除非需要,否则不会查询此表(并且对运行性能没有影响).(忽略了加载课程的一点开销.)

Answer 2

我被告知使用Java try-catch机制会有一些开销.

绝对.方法调用也有开销.但是你不应该把所有代码放在一个方法中.

不要试图过早优化号角,但重点应放在易于阅读,组织等方面.语言结构很少影响性能,就像系统组织和算法选择一样.

对我来说,第一个是最容易阅读的.