Java异常的四个问题

错误处理对于许多常见操作都很重要—从处理用户输入到发出网络请求。应用程序不应该仅仅因为用户输入无效数据或web服务返回错误而崩溃。用户希望软件能够优雅地处理错误，无论是在后台还是在用户友好且可操作的问题描述中。不幸的是，由于处理异常可能是混乱和复杂的，所以错误处理常常作为一个几乎被遗忘的最后一步来处理应用程序。

我们将介绍处理Java异常的四种方法。

1.例外情况很容易被忽略

Java的异常允许函数调用方忽略函数可能产生的任何错误。如果程序完全无法捕获异常，程序将崩溃。尽管忽略错误案例有助于构建快速原型，但在尝试为生产准备应用程序时，很难找到引发异常的所有位置。

Java引入了检查异常，试图通过要求用户对可能引发该异常的函数进行注释或立即捕获异常来解决此问题。虽然检查过的异常在某种程度上受到编译器的保护，但添加一个throws子句或将异常包装在try/catch块中仍然太容易，而不注意错误情况，也忽略了正确处理异常。此外，只检查了Java异常的一小部分，因此仍然很容易漏掉许多异常。

2.异常控制流很难遵循

如果异常是应用程序的常见部分，甚至是必不可少的部分，那么随着代码库变得越来越大、越来越复杂，理解代码库变得越来越困难。Java的异常发生在正常的函数模式之外，导致代码混乱和脆弱，而不是遵循通常通过参数和返回值的数据流。

3.正常事件被视为异常事件

通常，Java异常的使用方式会使正常行为看起来出人意料。例如，如果假定用户键入日期，但他们键入“hello”，则用于解析日期的代码可能会引发异常，而不是返回日期对象。突然之间，用户不遵循指导原则的非常普通的情况变成了例外情况，函数调用方负责记住处理异常。

作为另一个示例，假设当网络请求返回404NotFound错误时程序抛出异常。虽然客户端最初可能希望端点继续存在，但删除端点并不是不合理的。虽然在404响应上抛出异常最初看起来是个好主意，但它将常见事件视为异常事件，从而很容易忘记正确处理。

4.异常是运行时错误，而不是编译时错误

异常可用于处理异常状态；因此，在测试时很容易错过它们。虽然我们通常测试主要用户流和我们能想到的任何边缘情况，但错误情况通常被忽略，因为它们很难重现。异常也可能隐藏在您忘记测试的边缘案例中。

由于Java的异常是在运行时检查的，因此仅编译代码不足以确保正确处理错误案例。必须实际触发错误。但是，通常可以使用更好的类型，将错误检查从运行时检查转移到编译时检查。例如，使用Option而不是null可以帮助避免NullPointerExceptions。