在应用程序代码中使用Spring框架异常？

Question

使用框架提供的异常是否被视为不良做法？我正在使用Spring JDBC，我发现了这个IncorrectResultSizeDataAccessException异常，这正是我想要的。我将它从存储库层抛出。存储库和服务层已经知道我使用Spring所以它重要吗？

一般情况下，您是否会像这样创建自己的异常，或者如果可以使用框架提供的异常，您是否依赖它？

Answer 1

我不会在自己的代码中创建Spring代码依赖项。拥有一个依赖于Spring的实现是一回事，创建一个强制依赖于第三方框架的API只会通过API泄露实现细节。

我首先会看到是否存在符合用例的标准Java异常，如果没有，则创建一个自定义的异常。

Answer 2

出于多种原因，我会使用我自己定义的例外：

• 一些第三方框架。
• 不依赖于某些第三方框架版本 使用所需的例外。
• 可以设计我自己的未经检查或检查的异常层次结构，而我的应用程序需求正在规定我的异常设计（不是某些第三方框架）
• 可以轻松重构我的例外代码，添加/更新/删除方法。

我唯一看到的是，您最终可能会将某些第三方框架异常包装到特定于应用程序的异常中......例如。

try
{
  //...do something...
}
catch(SQLException e)
{
  throw new MyAppException(e);
} 

Answer 3

我认为没有理由为什么使用它实际上是不好的做法，我宁愿抛出预先存在的异常（因此，你和其他人可能更容易理解），而不是创建我自己的。

Answer 4

由于您的服务层已经使用了Spring，因此使用现有的Spring-JDBC异常似乎是合理的。最大的问题是，如果你的使用不符合Spring的使用方式，那么它可能会引起混淆。

如果您使用的是Spring JDBC，那么您已经依赖Spring代码，重用异常只会使异常处理更加统一。

Answer 5

我认为这是一个意见问题，可能更适合Programmers stack exchange。但IMO，这样做是可以的。我一直这样做，Java提供的异常就像IllegalArgumentException和类似的事情那么为什么不重用框架呢？

我能想到的缺点是，如果你在项目中替换Spring，那么你必须替换那个异常会有点奇怪。但我认为你不太可能首先这样做。

另外，因为其他层必须处理异常，所以你将spring代码暴露给那些层（因为它们必须在包中导入带有“spring”的异常），这可能是一个缺点。但这可能是反对异常的论据，而不是反对重复使用例外的论据。