在哪个命名空间/包中放置异常？
构建异常类位置的常见或最佳实践是什么？
假设您有包/命名空间 myproject.person （人员的模型和 DAO）和 myproject.order （订单的模型和 DAO）以及异常 PersonException 和 OrderException。我应该将异常放在相应的包中还是单独的异常包中（例如 myproject.exceptions）？
第一种方法似乎更合理（因为它是按功能排序的）。但问题就出现了，您应该在哪里放置与两者相关的异常？例如 ConstraintViolationException
What is the common or best practice to structure the location of your exception classes?
Let's say you have the packages/namespaces myproject.person (models and DAOs for persons) and myproject.order (models and DAOs for orders) and the exceptions PersonException and OrderException. Should I put the exceptions in their corresponding packages or in a separate package for exceptions (e.g. myproject.exceptions)?
The first approach seems more reasonable (because it's sorted by functionality). But there the question arises where you should put exceptions that are related to both? e.g. a ConstraintViolationException
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
做 Java 类库所做的事情。将异常放在与引发异常的 API 类和接口相同的包中。
Do what the Java class library does. Put the exceptions in the same packages as the API classes and interfaces that throw them.
根据我的经验，最好将异常放入对该异常有意义的包中。我不会仅仅为异常创建一个特殊的包 - 异常应该位于使用它们的类附近。
In my experience it is best to put exceptions into the packages that make sense for that exception. I wouldn't create a special package just for exceptions - the exceptions should live near the classes that use them.
我会将它们放在与其相应的类相同的命名空间中。对于更一般的异常类型，您应该尝试将它们放在最具体的命名空间中，该命名空间涵盖使用它们的类，因此 ConstraintViolationException 将放入 myproject 命名空间中。
I would put them in the same namespace as their corresponding classes. For more general exception types you should try to put them in the most specific namespace which covers the classes that use them, so ConstraintViolationException would go in the myproject namespace.
如果异常仅用于一个类或一组功能类，请将其放在靠近它们的位置。如果 Exception 对于应用程序 jr 库具有常见含义，则将其放入其 oun 命名空间中。
恕我直言
If exception uses only for one class or functuionality group of classes put it near them. If Exception have the common meaning for the application jr library, put it in its oun namespace.
IMHO
我对整个想法的问题是，异常通常应该按照可能出错的情况来设计，例如 NullPointerException ，而 PersonException 似乎引用对象参与正在发生的任何灾难，却没有给出问题出在哪里的线索。 Person 对象是否导致了异常？是因为 Person 存在内部逻辑问题，还是因为向其方法之一提供了错误的参数？或者是由于在数据库中找不到该人而导致的异常？
事实上，您对与这两个对象有关的例外情况有两种看法，这一事实只会加剧我的担忧。我建议重新考虑异常的设计（EntityNotFoundException、BadArgumentException、MinorCannotOrderPornException），您的困境的答案有望更加明显。
The problem I have with this whole idea is that exceptions should generally be designed along the lines of what can go wrong, such as
NullPointerException, whereasPersonExceptionseems to refer to the object involved in whatever disaster is unfolding without giving a clue as to what went wrong. Did the Person object cause the exception? Is it because the Person has an internal logic problem, or because bad arguments were supplied to one of its methods? Or was the exception due to the Person not being found in the database?The fact that you are in two minds about exceptions pertaining to both objects merely reinforces my concerns. I suggest rethinking the design of your exceptions (EntityNotFoundException, BadArgumentException, MinorCannotOrderPornException) and the answer to your dilemma will hopefully be more obvious.
想象一下，每个程序集都有自己的操作和许多类型的异常（不仅仅是 PersonException 或 OrderException，还有 PersonInvalidDataException 或 PersonDataPersistException< /强>）。
这些异常可以实现 BaseException，例如记录和发送电子邮件。
因此，更实惠的方法（在我看来）是按命名空间将它们分开。
Imagine that each assembly has its own operations, and many types of exceptions (not just PersonException or OrderException, but PersonInvalidDataException or PersonDataPersistException).
Those exceptions could implement a BaseException, that logs and send emails, for example.
So the more affordable way (in my opinion), is separating them by namespace.
我只是将所有异常保留在项目名称空间（即 myproject）中。如果您为每个类创建一个文件，它们可能会占用项目视图中的空间，因此我通常将该文件称为 (exceptions).cs，以便它们出现在顶部，并将所有异常放在一个位置。
如果它是一个大项目，那么通常会将程序集分解为不同的命名空间，每个命名空间都会有自己的一组异常，但我们正在谈论每个程序集超过 100 个类。
I just keep all the exceptions in the project namespace (ie myproject). They can take up space in a project view if you create one file per class, so I usually call the file (exceptions).cs so that they appear at the top, and place all the execeptions in one place.
If it is a big project, then generally a break the assemblies up into different namesspaces and each namespace will get its own set of exceptions, but we are talking over 100 classes per assembly.