构建异常类位置的常见或最佳实践是什么？
假设您有包/命名空间myproject.person（用于人员的模型和 DAO）和myproject.order（用于订单的模型和 DAO）以及异常PersonException和OrderException. 我应该将异常放在相应的包中还是放在单独的异常包中（例如myproject.exceptions）？
第一种方法似乎更合理（因为它是按功能排序的）。但是出现了一个问题，您应该在哪里放置与两者相关的异常？例如ConstraintViolationException
根据我的经验，最好将异常放入对该异常有意义的包中。我不会只为异常创建一个特殊的包——异常应该存在于使用它们的类附近。
做 Java 类库所做的事情。将异常放置在与抛出它们的 API 类和接口相同的包中。
我会将它们放在与其对应的类相同的命名空间中。对于更一般的异常类型，您应该尝试将它们放在涵盖使用它们的类的最具体的命名空间中，因此 ConstraintViolationException 将进入 myproject 命名空间。
如果异常仅用于一个类或一组功能性类，请将其放在它们附近。如果 Exception 对应用 jr 库有共同的含义，把它放在它的 oun 命名空间中。恕我直言
我对整个想法的问题是，异常通常应该按照可能出错的方向进行设计，例如NullPointerException, 而PersonException似乎是指涉及正在发生的任何灾难的对象，而没有给出出错的线索。Person 对象是否导致异常？是因为 Person 存在内部逻辑问题，还是因为向其中一个方法提供了错误的参数？还是由于在数据库中找不到 Person 导致的异常？
您对与这两个对象有关的异常有两种看法，这一事实只会加剧我的担忧。我建议重新考虑您的异常（EntityNotFoundException、BadArgumentException、MinorCannotOrderPornException）的设计，希望您的困境的答案会更加明显。
想象一下，每个程序集都有自己的操作，以及许多类型的异常（不仅仅是PersonException或OrderException，还有PersonInvalidDataException或PersonDataPersistException）。 这些异常可以实现一个 BaseException，例如记录和发送电子邮件。
所以更实惠的方式（在我看来）是按名称空间分隔它们。
我只是将所有异常保留在项目名称空间（即 myproject）中。如果您为每个类创建一个文件，它们会占用项目视图中的空间，因此我通常将文件 (exceptions).cs 称为文件，以便它们出现在顶部，并将所有异常放在一个位置。
如果它是一个大项目，那么通常会将程序集分解为不同的命名空间，每个命名空间都会有自己的一组异常，但我们说的是每个程序集有 100 多个类。