Java 若捕获空指针异常不是一个好的实践，那个么捕获异常是一个好的实践吗？

我听说捕获

NullPointerException

是一种不好的做法，我认为这是明智的做法。让

NullPointerException

传播到顶部将允许检测出某个错误。但是很多时候，我看到我的许多朋友直接捕获

异常

，这样他们就不必担心上述代码中可能出现的所有不同类型的异常。这是一种好的做法吗？还有哪些类型的异常最好不处理？此外，在确定异常源的特定代码上处理

NullPointerException

对我来说也是有意义的。那么，什么时候应该处理异常，什么时候不应该处理异常呢？什么样的异常列表最好不处理？

只有在可以增加一些值的情况下，才应该捕获异常。否则，您应该让它传递给调用方

NullPointerException通常是代码中的错误导致的。你怎样才能明智地在一个挡块中解决这个问题

---

不为异常而烦恼不是一种好的做法。

如果你有一种优雅的方式来处理你的异常，那么捕获它是很有用的，如果你不希望调用者有一种很好的方式来处理它。

口袋妖怪异常处理是不好的。特别是，如果它是一个空的街区，而你只是在吞下它们。您专门键入了异常，因为它们在特定上下文中实际上意味着特定的事情（本质上，它们告诉您出了什么问题）。因此，通过捕捉异常，你是在说你不在乎那些异常是什么，也不在乎发生了什么。这可能不是你想要的

通常，捕获异常时遵循以下规则：

• 在这个级别处理异常有意义吗？如果是，请处理它。如果没有，则传播
• 与第一条规则相结合，“处理”也可以指接住、包裹和重新投掷。这是一种防止抽象泄漏的方法，这样方法的调用方就不必知道底层实现
• 一个空的catch块并不意味着您已经处理了异常。这叫做“吞咽”；至少，您希望记录异常。有时发生的异常实际上是代码逻辑流的一部分，因此您可能需要做一些特殊的事情（请原谅，这是双关语，异常而不是规则。最好检查导致异常的情况，而不是将它们合并到代码逻辑流中）

您可以轻松地检查代码中的空值，因此无需显式捕获空指针异常。让

NullPointerException

发生是没有意义的（这是一种糟糕的做法）。即使您有一些代码抛出一个

NullPointerException

，而这是您无法控制和修复的代码，您也应该确定导致

NullPointerException

的输入参数，并专门测试它们

---

另一个不应该捕捉的异常是

IllegalArgumentException

。此异常意味着您传入了一个没有意义的参数。与其捕获此异常，不如显式测试输入参数，以确保它们是正常的，并且不会导致

非法argumentexception

捕获异常的主要规则是，您必须知道为什么要这样做。当程序员想要进行一般性错误处理时，异常类会被捕获，而他并不真正关心到底发生了什么，主要的是出了什么问题。在这种情况下，他可能决定回滚事务或进行一些清理。

---

如果捕获特定异常，请尝试应用相同的规则。我知道你为什么要这么做，那就是这么做了。但在NPE中，很少有人想做一些真正特别的事情

捕获

NullPointerException

被认为是一种不好的做法的“原因”并不是因为当出现问题时你应该让它冒泡出来！说任何异常都是“最好不处理”的，仅仅基于它的类型，这似乎是个坏主意

NPE被认为是编程错误的结果。一个严格正确的程序不应该生成一个。看到它被捕获的原因是不好的，因为它通常意味着代码抛出了一个，程序员决定只捕获它并掩盖它，而不是修复导致它的坏代码

例如，如果您出于业务原因连接到一个内部有bug的API，并且偶尔抛出一个空指针，那么捕获它、处理它/用更好的消息通知用户是完全合法的。仅仅因为有人说“捕捉空指针异常不好”，就让“null”进入用户界面是没有意义的

---

捕获

java.lang.Exception

在特定情况下是合法的，但通常“我很懒”不是其中之一例如，如果您正在实现一个API，并且希望绝对确保不会出现规范中没有的异常，您可能会捕获异常并将其包装到您定义的某个应用程序异常中。

通常，您应该捕获异常的唯一时间是您是否能够以某种有意义的方式处理它。如果你不能，你应该简单地让它冒泡到顶部，并终止这个过程。例如，您能否以某种有意义的方式从NullPointerException或I/O错误中恢复？我想不是

我的异常处理规则：

• 一般来说，不要捕获异常，除非您能够以某种有意义的方式处理它们
• 在进程/计算机边界捕获异常，记录捕获的异常