在应用程序代码中使用Spring框架异常?
使用框架提供的异常被认为是不好的做法吗?我使用的是Spring JDBC,我发现这个异常正是我想要的。我将从存储库层中抛出它。存储库和服务层已经知道我使用Spring所以它是否重要?在应用程序代码中使用Spring框架异常?
一般情况下,您是否会创建自己的例外,或者如果可以使用,您是否依赖框架提供的例外?
我不惜用我自己定义的例外有许多原因:
- 有多更好的生活周期的版本了我的异常VS 一些第三方框架控制。
- 请勿依赖某些第三方框架的版本以便使用所需的例外,其编号为 。
- 可以设计自己的未检查或检查的异常层次结构,我的应用需求使唤我的异常设计(而不是一些第三方框架)
- 可以轻松修改我的异常的代码,添加/更新/删除方法。
我看到的唯一的结果是,你可能会最终将某些第三方框架异常包装到你的应用程序特定异常中......例如,
try
{
//...do something...
}
catch(SQLException e)
{
throw new MyAppException(e);
}
我认为这是一个意见问题,可能更适合Programmers stack exchange。但国际海事组织,这可以做到这一点。我一直这样做,除了Java为IllegalArgumentException和类似的东西提供的例外,那么为什么不重用一个框架呢?
我能想到的一个缺点是,如果您在项目中替换Spring,那么您必须更换该异常会有点奇怪。但我认为这不太可能会首先做到这一点。另外,因为其他图层必须处理异常,所以您将Spring代码暴露给这些图层(因为它们必须在包中导入包含“spring”的异常),这可能是一个缺点。但是这可能是反对异常的一个论据,而不是反对重用异常的论据。
我不会在我自己的代码中创建Spring代码依赖项。取决于Spring的实现是一回事,创建一个强制依赖第三方框架的API只需通过API调出实现细节。
我会先看看是否有符合用例的标准Java异常,如果没有,则创建一个自定义的异常。
我没有看到为什么使用它真的是不好的做法,我宁可抛出事先存在的异常(因此,更容易理解你和别人出现的异常),而不是创建我自己的异常。
由于您的服务层已经使用Spring,因此使用现有的Spring-JDBC异常似乎是合理的。最大的问题是,如果你的使用不符合Spring的使用方式,那么它可能会引起混淆。
如果您使用的是Spring JDBC,则您已经对Spring代码有依赖关系,重新使用该异常只会使异常处理更加统一。