12778
spring を扱っている人たちの間で、Checked Exception を取り扱うよりは、 Unchecked Exception を取り扱うほうが、
Spring Philosophy に合致している、という話を耳にします。

たとえば、次の本家SO の答えの最初の行です。  
<https://stackoverflow.com/a/24401798>

具体的に、これ(Unchecked Exception を使うこと)がどうして、  
Spring philosophy に合致しているのかについての、  
説明ないし、ソースを見つけられずにいるのですが、  
ご存知の方はいらっしゃいますでしょうか。
CC BY-SA 3.0
2015-07-27T14:48:21.897
12750
2015-07-28T13:48:01.860
2017-05-23T12:38:55.250
-1
754
question
java spring
unchecked exception の方が checked exception より spring philosophy に合致している理由/ソース
Checked/Unchecked Exceptionと"Spring philosophy"との関係への言及は、[Spring Framework
Reference Documentation](http://docs.spring.io/spring/docs/current/spring-
framework-reference/htmlsingle/#transaction-strategies)で見つけられます。

> 12.3 Understanding the Spring Framework transaction abstraction  
>  [...]  
>  Again in keeping with Spring's philosophy, the `TransactionException` that
> can be thrown by any of the `PlatformTransactionManager` interface's methods
> is _unchecked_ (that is, it extends the `java.lang.RuntimeException` class).
> Transaction infrastructure failures are almost invariably fatal. In rare
> cases where application code can actually recover from a transaction
> failure, the application developer can still choose to catch and handle
> `TransactionException`. The salient point is that developers are not
> _forced_ to do so.

直接的に"Spring philosophy"を定義する文書は見つけられなかったのですが、[Announcing Spring Framework 4.0
GA Release](http://spring.io/blog/2013/12/12/announcing-spring-
framework-4-0-ga-release)にphilosophyとprinciplesについての言及がありました。

> The Spring Framework project page is always a great start. But we've worked
> hard on new guides to accompany the launch of the Framework. In keeping with
> our philosophy of "let's build a better enterprise" we've developed these
> getting started guides with a few principles:
>
>   * Be the simplest possible example, not the "best", as that is subjective
>   * Use the most up-to-date Spring best practices
>   * Do not give in to the temptation to become a full-blown tutorial, keep
> those separate
>   * Make assumptions. Separate underlying concepts into linked, distinct
> documents
>   * Stay task oriented, use case-oriented, explain things beyond Spring when
> relevant
>   * Above all, be a resource that experts and beginners alike can appreciate
>
CC BY-SA 3.0
2015-07-28T03:15:55.860
12758
2015-07-28T03:15:55.860
49
12750
answer
SpringのコアはDIコンテナです。DI（依存性の注入）を導入する目的は、利便性など色々ありますが、最大の目的はコンポーネント間の結合度を下げることにあります。

対して検査例外は、プロシージャ内部で発生したエラーが、回復可能であることを呼び出し元に通知する仕組みです。

呼び出し元コンポーネントが例外をハンドリングするということは、子コンポーネントの実装の詳細を知る必要があるということです。これはDIの概念と真っ向から衝突します。

分かりやすい例が`SQLException`です。

Springを使う場合、データベースから業務データを`Bean`で取得するケースも多いと思いますが、一般的なJavaでデータベースを扱う場合、`SQLException`のハンドリングは避けられません。しかし、`SQLException`が返却するエラーコードはDB製品固有のものであり、コンポーネントの密結合化に繋がります。

そこで、Springでは検査例外の`SQLException`を、非検査例外の`DataAccessException`に抽象化することで、コンポーネント内部で例外が閉じるような設計に矯正しています。

* * *

加えて、SpringではDIコンテナにAOP（アスペクト指向プログラミング）を連携させることで、例外処理を挿入したハンドラインスタンスに行わせることができます。

業務例外やシステム例外の処理を、それぞれのロジックに書くのではなく、振る舞いのみを抽出して横断的に処理をする、「関心の分離」というやつです。

この辺りの概念に通じてくると、自然と検査例外に対して、

  * コンポーネント間で実装の詳細を共有する必要が生まれ、疎結合化を阻害する
  * 検査例外は例外処理のボイラープレートコードを強制し冗長である

という思考が生まれて、「非検査例外を使用する」という方向に寄るんじゃないんでしょうか。
CC BY-SA 3.0
2015-07-28T13:48:01.860
12778
2015-07-28T13:48:01.860
5337
12750
answer