当然，规则总是有例外，但是如果您需要经验法则，那么您是正确的。空捕获块是“绝对”的坏习惯。
让我们仔细看看，首先从您的特定示例开始：
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）：
您知道当您阅读的每个例程几乎都符合您的预期时，您正在使用干净的代码。 当代码也使它看起来像是针对问题而设计的语言时，可以将其称为精美代码。
让它沉入其中并进行冥想。干净的代码并 不会 令你大吃一惊。您向我们展示的示例让 每个人都 惊讶。
更新 ，关于OP要求的更新
try { do something}catch(Exception e) { print stacktrace}同样的答案：“到处都是”也是 不好的 做法。因为此代码 也 使读者感到惊讶。
以上：
- 在某处打印错误信息。完全 不能 保证此“某处”类似于 合理的 目的地。与此相反的。示例：在我正在使用的应用程序中，此类调用会神奇地出现在我们的跟踪缓冲区中。根据具体情况，有时我们的应用程序可能会向这些缓冲区中注入大量数据。每隔几秒钟进行一次缓冲修剪。因此，“仅打印错误”通常会翻译为：“仅丢失所有此类错误信息”。
- 然后：您不可以尝试/捕获，因为 可以 。之所以这样做，是因为您了解自己的代码在做什么；而且您知道：我最好在这里尝试一下/做对的事情（再次参见答案的第一部分）。
因此，将try / catch用作显示的“模式”；就像这样说：仍然不是一个好主意。是的，它 可以防止
崩溃；但会导致各种“未定义”行为。您知道，当您只是捕获异常而不是 适当地 处理它时；你打开一罐蠕虫；因为您可能会遇到无数 后续
错误，这些错误后来您都无法理解。因为您之前消耗了“根本原因”事件；印在某处 那个 地方 现在不见了。
