我一直在开发一个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试图捕获异常为 不同 的目的不是这个问题。