1

使用框架提供的异常是否被认为是不好的做法？我正在使用 Spring JDBC，我发现这个IncorrectResultSizeDataAccessException异常正是我想要的。我将从存储库层扔掉它。存储库和服务层已经知道我使用了 Spring 那么这有关系吗？

一般来说，您会像这样创建自己的异常，还是依赖框架提供的异常（如果可以使用）？

4

5 回答 5

2

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

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

于 2013-03-18T18:49:04.327 回答
2

出于多种原因，我会求助于我自己定义的异常：

  • 与某些第三方框架相比，对我的异常有更好的生命周期版本控制。
  • 不要依赖某些第三方框架版本来使用所需的异常。
  • 可以设计我自己的未检查或检查异常层次结构，并且我的应用程序需求决定了我的异常设计（不是某些第三方框架）
  • 可以轻松重构我的异常代码，添加/更新/删除方法。

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

try
{
  //...do something...
}
catch(SQLException e)
{
  throw new MyAppException(e);
}
于 2013-03-18T18:57:49.527 回答
1

我看不出为什么使用它真的是不好的做法，我宁愿抛出预先存在的异常（因此，如果它们出现，你和其他人更容易理解）而不是创建自己的异常。

于 2013-03-18T18:49:38.537 回答
1

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

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

于 2013-03-18T19:05:58.760 回答
0

我认为这是一个见仁见智的问题，可能更适合程序员堆栈交换。但是IMO，这样做是可以的。我一直都在处理 Java 为我提供的异常，例如 IllegalArgumentException 之类的东西，那么为什么不重用一个框架呢？

我能想到的缺点是，如果您在项目中替换 Spring，则必须替换该异常会有点奇怪。但我认为你不太可能一开始就这样做。

此外，由于其他层必须处理异常，因此您将弹簧代码暴露给这些层（因为它们必须在包中导入带有“spring”的异常），这可能是一个缺点。但这可能是反对异常的论据，而不是反对重用异常的论据。

于 2013-03-18T18:46:56.003 回答