使用框架提供的異常被認爲是不好的做法嗎?我使用的是Spring JDBC,我發現這個異常正是我想要的。我將從存儲庫層中拋出它。存儲庫和服務層已經知道我使用Spring所以它是否重要?在應用程序代碼中使用Spring框架異常?
一般情況下,您是否會創建自己的例外,或者如果可以使用,您是否依賴框架提供的例外?
使用框架提供的異常被認爲是不好的做法嗎?我使用的是Spring JDBC,我發現這個異常正是我想要的。我將從存儲庫層中拋出它。存儲庫和服務層已經知道我使用Spring所以它是否重要?在應用程序代碼中使用Spring框架異常?
一般情況下,您是否會創建自己的例外,或者如果可以使用,您是否依賴框架提供的例外?
我不惜用我自己定義的例外有許多原因:
我看到的唯一的結果是,你可能會最終將某些第三方框架異常包裝到你的應用程序特定異常中......例如,
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代碼有依賴關係,重新使用該異常只會使異常處理更加統一。