为什么捕获RuntimeException并不是一种好的编程习惯？
为什么捕获RuntimeException使用catch(Throwable exc) {}不被视为良好的编程习惯？什么是处理RuntimeException的正确方法？
另外，为什么不catch(Exception exc) {}赶上RuntimeException？如何执行此行为？
问题答案：
通常，a RuntimeException表示编程错误（在这种情况下，您无法“处理”该错误，因为如果您知道期望发生错误，则可以避免该错误）。
捕获任何这些常规异常（包括Throwable）都是一个坏主意，因为这意味着您声称自己了解所有可能出错的情况，尽管如此，您仍然可以继续。有时Exception（而不是通常Throwable）捕获堆栈的顶层是适当的，例如在Web服务器中-
因为通常 _单个_请求出了什么问题，您通常希望保持服务器正常运行并响应其他请求。我通常不会捕获Throwable，因为其中包括Error通常用于指示真正灾难性错误的子类，通常最好通过终止过程来“处理”这些错误。
从根本上讲，当出现错误时，您需要对继续执行特定任务非常谨慎-您需要对错误的含义有一个非常好的了解，否则您可能会对世界状况做出错误的假设，并使情况变得更糟。在
_大多数_情况下（并非全部），简单地放弃请求要比尝试继续进行下去要好，而不管发生什么神秘的失败。（尽管它确实很大程度上取决于上下文，例如，您可能不关心尝试获取一条辅助信息时出了什么问题。）
至于抓Exception不抓RuntimeException-那是不正确的。唯一奇怪的RuntimeException是，它（和子类）是未经检查的异常，而的Exception所有其他子类Exception都经过检查。
-
问题内容： 我经常看到有关不鼓励使用的其他问题的评论。为什么这样不好？有时我只是不在乎错误是什么，我只想继续编写代码。 为什么使用积木不好？是什么让它不好？是我pass出错还是我except出错了？ 问题答案： 正如你正确猜到的那样，它有两个方面：通过在后面不指定任何异常类型来捕获任何错误，并在不采取任何操作的情况下简单地传递它。 我的解释要“长一点”，因此; 可以细分为： 不要发现任何错误。始终
-
问题内容： 我听说捕捞是一种不好的做法，我认为这样做是明智的。让传播到顶部将允许检测出问题。但是很多时候我已经看到很多朋友直接被捕获，因此他们不必理会上面代码中可能发生的所有不同种类的异常。这是一个好习惯吗？还有哪些其他最好不处理的例外情况？此外，对我来说，处理一个确定了异常源的特定代码对我来说也很有意义。那么什么时候处理异常，什么时候不应该处理？最好不处理的异常清单可能是什么？ 问题答案： 宠物
-
问题内容： 在最近的项目中，我建议在测试工具代码中捕获RuntimeException并将其记录下来。该代码处理来自数据库的一系列输入，并且我不希望由于任何一个输入（空值，非法参数等）失败而导致测试停止。不用说，我的建议引起了热烈的讨论。 捕获任何一种RuntimeException是否可以接受？如果是，那么可以捕获RuntimeExceptions的其他方案还有哪些？ 问题答案： 捕获此异常的原
-
假设我们有以下程序： 基于Java文档： > 为什么只在运行时抛出？ 编译器缺少哪些信息来意识到该赋值是不可能的？
-
问题内容： 我的建筑师总是说 永远不要同步布尔值 我无法理解原因，如果有人可以举例说明为什么这不是一个好习惯，我将不胜感激。 参考样本代码 问题答案： 我不明白为什么我们应该“从不同步布尔值” 你应该始终synchronize在一个常量对象实例上。如果你在分配的任何对象上进行同步（即，将对象更改为新对象），则该对象不是恒定的，并且不同的线程将在不同的对象实例上进行同步。由于它们在不同的对象实例上进
-
问题内容： 我正在编写自己的容器，该容器需要通过属性调用来访问内部的字典。容器的典型用法如下： 我知道写这样的东西可能很愚蠢，但这就是我需要提供的功能。我正在考虑通过以下方式实现此目的： 我不确定嵌套的try / except块是否是一个好习惯，所以另一种方法是使用and ： 或者使用其中之一，然后尝试使用catch块，如下所示： 哪个选项最适合pythonic和优雅？ 问题答案： 您的第一个例子