【问题标题】:To declare or not declare DataAccessException in DAO interface methods?在 DAO 接口方法中声明或不声明 DataAccessException?
【发布时间】:2012-07-09 09:39:24
【问题描述】:

我看到一些 Spring/Hibernate 代码对在 DAO 接口方法中声明 DataAccessException 有不同的策略。

有些会明确声明,有些则不会(或只是偶尔):

public interface FlightDao {

    boolean decrementSeat(Long flightId, int quantity);

    List<Flight> findFlights(String fromAirportCode, String toAirportCode) throws DataAccessException;

    public List<Flight> getFlights();

    Flight getFlight(Long id);

    Flight getFlight(String flightNumber);

    void save(Flight flight);

}

最佳实践是什么?为什么?

更新

spring tutorial 的第 13.2.2 节开始,使用 @Repository 注释实现 DAO pojo 以确保将底层 ORM(或 JDBC)异常自动转换为 DataAccessException(运行时)异常层次结构非常重要。

【问题讨论】:

    标签: java spring exception dao


    【解决方案1】:

    如您所见here,这是一个RuntimeException,所以无论您是否声明它在编程方面都没有区别。当用户实现该方法时,他可以选择从方法签名中省略此异常。

    我能想到将它放在方法签名中的唯一原因是标记它,以便用户知道此方法可能会抛出此异常,因此他可以选择是否捕获并处理它。

    【讨论】:

      【解决方案2】:

      如果在查找航班/获取航班/减少座位时出现任何类型的异常,调用这些“服务”方法的应用程序应该对如何处理这些异常有最终决定权。作为服务的 FlightDAO 应该简单地捕获并抛出所有异常。您可能会发现创建一个新的用户定义的异常很有用...调用它 ServiceException 或 MyDAOException 并使 FlightDAO 中的所有方法都抛出这个用户定义的异常。

      【讨论】:

      • 我不太确定这个策略,因为通过让这些运行时异常爬栈,Spring会在事务级别(如果有的话)捕获它们,从而触发回滚。跨度>
      • 是的。如果是插入操作并且出现异常,则弹簧容器应回滚。但我仍然认为向调用者抛出异常是必不可少的。如果您要说 getFlights 并且存在运行时异常,那么调用此服务的应用程序会发现知道航班列表是否为空是很有用的,因为存在异常而不是因为该查询没有航班。
      猜你喜欢
      • 1970-01-01
      • 2014-02-02
      • 1970-01-01
      • 2012-05-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-03-24
      • 1970-01-01
      相关资源
      最近更新 更多