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

Question

// 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块中。即使对于永远不会抛出任何异常的函数也是如此。

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

  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试图捕捉异常的目的不同于这个问题。

Answer 1

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

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

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

null

正如其他人所指出的那样：您还可以避免在一般情况下捕获异常（嗯，这取决于层：可能有很好的理由对异常进行捕获，甚至在最高级别捕获某些类型的错误，以确保没有丢失任何东西；永远）。

最后，让我们引用沃德·坎宁安的话：

当您读到的每个例程都与您所期望的差不多时，您就知道您正在使用干净的代码。当代码也使它看起来像是为问题而设计的语言时，你可以称之为美丽的代码。

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

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

以上所述：

• 在某处打印错误信息。根本不能保证这个“某处”类似于一个合理的目的地。恰恰相反。示例：在我正在使用的应用程序中，这样的调用会神奇地出现在我们的跟踪缓冲区中。根据上下文，我们的应用程序有时可能会将数吨的数据泵入这些缓冲区；使这些缓冲区每隔几秒钟修剪一次。因此，“只是打印错误”通常会转化为：“只是丢失所有此类错误信息”。
• 然后：你不做尝试/捕捉，因为你可以。你这样做是因为你明白你的代码在做什么；你知道：我最好尝试一下/抓住这里来做正确的事情（请再看我答案的第一部分）。