使用 try/catch 防止应用程序崩溃

Question

我一直在开发一个 Android 应用程序，它经常使用 try/catch 以防止它在不需要的地方崩溃。例如，

xml layout 中的视图 id = toolbar 被引用为：

 // see new example below, this one is just confusing
// it seems like I am asking about empty try/catch
try {
    View view = findViewById(R.id.toolbar);
}
catch(Exception e) {
}

整个应用程序都使用这种方法。堆栈跟踪没有打印出来，真的很难找到哪里出了问题。该应用程序突然关闭而不打印任何堆栈跟踪。

我请我的前辈向我解释，他说，

这是为了防止生产崩溃。

我完全不同意。对我来说，这不是防止应用程序崩溃的方法。它表明开发人员 不 知道他/她在做什么并且有疑问。

这是业界用来防止企业应用程序崩溃的方法吗？

如果 try/catch 确实是我们的需要，那么是否可以将异常处理程序附加到 UI 线程或其他线程并捕获那里的所有内容？如果可能的话，这将是一个更好的方法。

是的，空的 try/catch 是不好的，即使我们向服务器打印堆栈跟踪或记录异常，将代码块包装在 try/catch 中随机跨所有应用程序对我来说没有意义例如当每个函数都包含在 try/catch 中时。

更新

由于这个问题已经引起了很多关注并且有些人误解了这个问题（也许是因为我没有清楚地表述它）我将重新表述它。

这是开发人员在这里做的事情

• 编写并 测试 了一个函数，它可以是一个只初始化视图的小函数，也可以是一个复杂的函数，测试后它被包裹在 try/catch 块中。即使是永远不会抛出任何异常的函数。

• 在整个应用程序中都使用这种做法。有时会打印堆栈跟踪，有时只会打印 debug log 以及一些随机错误消息。此错误消息因开发人员而异。

• 使用这种方法，应用程序不会崩溃，但应用程序的行为变得不确定。甚至有时很难找出哪里出了问题。

• 我一直在问的真正问题是； 防止企业应用程序崩溃是业界正在遵循的做法吗？ 我不是在问 空的 try/catch 。与行为异常的应用程序相比，用户更喜欢不会崩溃的应用程序吗？因为它真的归结为要么崩溃，要么向用户呈现空白屏幕，或者用户没有意识到的行为。

• 我在这里发布了一些真实代码的片段

    private void makeRequestForForgetPassword() {
      try {
          HashMap<String, Object> params = new HashMap<>();

          String email= CurrentUserData.msisdn;
          params.put("email", "blabla");
          params.put("new_password", password);

          NetworkProcess networkProcessForgetStep = new NetworkProcess(
              serviceCallListenerForgotPasswordStep, ForgotPassword.this);
          networkProcessForgetStep.serviceProcessing(params,
              Constants.API_FORGOT_PASSWORD);
      } catch (Exception e) {
          e.printStackTrace();
      }
  }

   private void languagePopUpDialog(View view) {
      try {
          PopupWindow popupwindow_obj = popupDisplay();
          popupwindow_obj.showAsDropDown(view, -50, 0);
      } catch (Exception e) {
          e.printStackTrace();
      }
  }

  void reloadActivity() {
      try {
          onCreateProcess();
      } catch (Exception e) {
      }
  }

它 不是 Android 异常处理最佳实践 的副本，OP 正试图为与此问题 不同 的目的捕获异常。

原文由 mallaudin 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

当然，规则总是有例外，但如果你需要一个经验法则——那么你是对的；空的 catch 块“绝对”是不好的做法。

让我们仔细看看，首先从您的具体示例开始：

 try {
  View view = findViewById(R.id.toolbar);
}
catch(Exception e) { }

因此，创建了对某物的引用；当失败时……没关系；因为首先没有使用该参考！上面的代码绝对是 无用的线路噪声。或者编写该代码的人是否最初假设第二个类似的调用会神奇地不再抛出异常？！

也许这看起来像：

 try {
  View view = findViewById(R.id.toolbar);
  ... and now do something with that view variable ...
}
catch(Exception e) { }

但是，这又有什么用呢？！存在异常以 在您的代码中分别传播 错误 情况。忽略错误很少是一个好主意。实际上，可以通过以下方式处理异常：

• 您向用户提供反馈； （例如：“您输入的值不是字符串，请重试”）；或者进行更复杂的错误处理
• 也许这个问题在某种程度上是可以预料到的并且可以缓解（例如，当某些“远程搜索”失败时给出“默认”答案）
• …

长话短说：您对异常所做的 最起码 的事情是记录/跟踪它；这样当你稍后调试一些问题时，你就会明白“好的，此时异常发生了”。

正如其他人所指出的那样：您通常也会避免捕获 Exception （好吧，取决于层：可能有充分的理由对 Exception 进行捕获，甚至在最高级别捕获某些类型的错误，以确保 什么 都不会丢失； 永远）。

最后，让我们 引用 Ward Cunningham 的话：

当您阅读的每个例程都非常符合您的预期时，您就知道您正在使用干净的代码。当代码看起来像是为解决问题而设计的语言时，您可以称其为漂亮的代码。

让它沉入其中并对其进行冥想。干净的代码 不会 让你感到惊讶。您向我们展示的示例让 所有 在看的人都感到惊讶。

Update ，关于 OP 询问的更新

try {
  do something
}
catch(Exception e) {
  print stacktrace
}

同样的答案：“到处”这样做也是 不好的 做法。因为这段代码 也 让读者大吃一惊。

以上：

• 在某处打印错误信息。完全 不能 保证这个“某处”类似于一个 合理 的目的地。从相反的方面来说。示例：在我正在使用的应用程序中，此类调用会神奇地出现在我们的跟踪缓冲区中。根据上下文，我们的应用程序有时可能会将大量数据泵入这些缓冲区；每隔几秒钟对这些缓冲区进行修剪。所以“只是打印错误”通常翻译为：“只是丢失所有此类错误信息”。
• 然后：你不做 try/catch 因为你 _可以_。你这样做是因为你了解你的代码在做什么；而且您知道：我最好在这里尝试/抓住以做正确的事情（再次参见我的回答的第一部分）。

因此，像您展示的那样使用 try/catch 作为“模式”；正如所说：仍然不是一个好主意。是的，它 可以防止 崩溃；但会导致各种“未定义”行为。您知道，当您只是捕获异常而不是 正确 处理它时；你打开了一罐蠕虫；因为您可能会遇到无数您以后不理解的 后续 错误。因为您之前消耗了“根本原因”事件；打印在某处；那个 地方 现在不见了。

原文由 GhostCat 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

来自 Android 文档：

让我们将其命名为 -

不要捕获一般异常

在捕获异常时偷懒也很诱人，可以做这样的事情：

 try {
    someComplicatedIOFunction();        // may throw IOException
    someComplicatedParsingFunction();   // may throw ParsingException
    someComplicatedSecurityFunction();  // may throw SecurityException
    // phew, made it all the way
} catch (Exception e) {                 // I'll just catch all exceptions
    handleError();                      // with one generic handler!
}

在几乎所有情况下，捕获通用 Exception 或 Throwable（最好不是 Throwable，因为它包含错误异常）都是不合适的。这是非常危险的，因为这意味着您从未预料到的异常（包括 RuntimeExceptions 就像 ClassCastException ）在应用程序级错误处理中被捕获。

它掩盖了代码的故障处理属性，这意味着如果有人在您调用的代码中添加了一种新类型 Exception ，编译器将不会帮助您意识到您需要以不同方式处理错误。

捕获通用异常的替代方法：

• 一次尝试后，将每个异常分别捕获为单独的 catch 块。这可能很尴尬，但仍然比捕获所有异常更可取。

作者编辑： 这是我的选择。 当心在 catch 块中重复过多的代码。如果您使用的是 Java 7 或更高版本，请使用 multi-catch 以避免重复相同的 catch 块。 - 使用多个 try 块 重构您的代码以获得更细粒度的错误处理。将 IO 从解析中分离出来，在每种情况下分别处理错误。 - 重新抛出异常。很多时候无论如何都不需要在这个级别捕获异常，只需让方法抛出它即可。

在大多数情况下，您不应该以相同的方式处理不同类型的异常。

此答案的格式/段落从源代码中略有修改。

PS 不要害怕异常！！他们是朋友！！！

原文由 Paresh P. 发布，翻译遵循 CC BY-SA 3.0 许可协议