异常处理是否是跨领域的关注点？

我对异常处理和日志记录的关注并没有多大区别，因为两者都是跨领域的关注。你怎么看？它不应该单独处理而不是与方法实现的核心逻辑交错处理吗？

编辑：我想说的是，在我看来，方法实现应只包含成功执行路径的逻辑，而异常应在其他地方处理。这与已检查/未检查的异常无关。

例如，一种语言可以通过使用如下结构以完全检查的方式处理异常：

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

在上述概念性语言中，程序在没有FileReader 处理程序的情况下将无法编译，因为FileReader 类的readFile不会引发异常。因此，通过声明FileReader 处理程序，编译器可以确保对其进行处理，然后程序可以进行编译。

这样，我们就可以同时处理已检查和未检查的异常问题：健壮性和可读性。

在某些情况下是

如果您有要记录的异常（我认为几乎总是这样），则是，该异常与跨领域关注相关。

大多数时候没有

但是，以SocketListener为例，如果套接字监听器由于另一端断开连接而引发异常，则这应该是预期的行为，因此应用程序应根据导致异常的情况进行操作。这不是通用方面应该处理的事情，因此不应成为跨领域关注的问题。

确定跨领域关注点

如果要一遍又一遍地复制相同的代码，则需要对其进行抽象。如果抽象将自身提升到多个层次，则可能是一个横切关注点。只有那时才应考虑。

日志记录是可选的。不是例外。

日志记录是非常通用的，虽然它从特定的逻辑中获取信息，但却提供给通用使用者。异常始终是逻辑所特有的，并且某些了解该逻辑的代码必须处理其产生的混乱。

至少在我有限地使用两者的情况下，这意味着最好以不同的方式而不是在相同的设计框架下处理两个目标。

我将异常处理视为某些类型的异常的跨领域关注点。存在局部异常，只有立即调用的代码才能正确处理。一个示例可能是尝试执行查询时的数据库异常。但是也存在可以并且应该在全球范围内处理的例外情况。一个示例可能是与缺少安全凭据有关的异常（强制用户再次登录）。或者至少，您需要一个全局处理程序，以防异常滑过更具体的代码，以向用户解释他们应该如何重启或将日志发送给IT等。对于这些类型的全局处理的异常，这是一个跨领域的问题。

我认为这与泄漏抽象的问题有关。

当它们通过抽象层传播时，应捕获并抛出许多异常。重新抛出应该以适合于进行重新抛出的抽象的新形式抛出异常，以便将其作为接口的一部分有意义。换句话说，来自较低抽象级别的异常应转换为电流抽象形式，以便较高抽象级别不需要了解较低级别，即使是纯粹用于异常处理也是如此。

但是，“泄漏抽象的原理”是一个问题。某些异常无法转换为在抽象的下一层有意义的形式。

与网络文件系统相关的异常是一个简单的示例。网络故障不能用对“文件”抽象有意义的术语来表示，或者，如果确实如此，则该抽象还没有真正完全抽象出与文件处理的实现有关的所有细节。

因此，网络故障会从基础网络抽象中泄漏出来，因此在其余代码中必须成为跨领域的关注点。

但是，这并非异常所独有。所有与文件抽象无关的文件API的所有返回值错误代码，而是详细描述了硬盘或网络或任何故障，它们以不同的形式出现在同一事物中，这意味着硬盘故障和网络故障不管如何报告这些失败，等等都是横切关注的问题。