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

Question

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

xml layout 中带有 id = toolbar 的 View 的引用如下:

// 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) {
}

此方法在整个应用程序中使用。堆栈跟踪没有打印出来，很难找到问题所在。应用突然关闭，没有打印任何堆栈跟踪。

我让我的学长向我解释，他说，

This is for preventing crashing in production.

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

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

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

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

更新

由于这个问题引起了很多关注并且有些人误解了这个问题(可能是因为我没有清楚地表达它)我将重新表达它。

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

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

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

• 使用这种方法，应用不会崩溃，但应用的行为会变得不确定。甚至有时也很难追查到底出了什么问题。

• 我一直在问的真正问题是； 这是防止企业应用程序崩溃的行业惯例吗？我不是在问empty try/catch。是不是用户喜欢不会崩溃的应用程序而不是行为异常的应用程序？因为它真的归结为要么崩溃，要么给用户一个空白屏幕，或者用户不知道的行为。

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

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

It is not duplicate of Android exception handling best practices, there OP is trying to catch exception for a different purpose than this question.

Answer 1

当然，规则总有异常(exception)，但如果您需要经验法则 - 那么您是正确的；空的 catch block 是“绝对”不好的做法。

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

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(嗯，取决于层:可能有充分的理由捕获 Exception，甚至是最高级别的一些错误，以确保没有丢失；永远)。

最后，让我们 quote沃德坎宁安:

当您阅读的每个例程都与您预期的差不多时，您就知道您正在使用干净的代码。当代码看起来像是为问题设计的语言时，你可以称它为漂亮的代码。

让它沉入其中并冥想它。干净的代码不会让您感到惊讶。您向我们展示的示例让每个人都感到惊讶。

更新，关于 OP 询问的更新

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

同样的答案:“到处”这样做也是不好的做法。因为这段代码也让读者感到惊讶。

以上:

• 在某处打印错误信息。 根本不保证这个“某处”类似于一个合理的目的地。从相反的方面来说。示例:在我正在使用的应用程序中，此类调用会神奇地出现在我们的跟踪缓冲区中。根据上下文，我们的应用程序有时可能会向这些缓冲区中注入(inject)大量数据；每隔几秒钟就修剪一次这些缓冲区。因此，“只是打印错误”通常翻译为:“只是丢失所有此类错误信息”。
• 那么:你不会尝试/捕捉，因为你可以。你这样做是因为你了解你的代码在做什么；而且您知道:我最好在这里尝试/捕获以做正确的事情(再次查看我的答案的第一部分)。

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