Clojureはチェックされていない例外を含むチェック例外をなぜラップするのですか？

Question

次のコードは、チェックされた例外ExecutionExceptionが操作によってスローされ、ClojureがRuntimeExceptionでラップしている場合を示しています。

なぜClojureがこれをやっているのですか？これは正常ですか？この場合、ClojureはJavaとは異なる何かをしているように見えます。障害の原因となった実際の例外を処理する慣用的な方法は、この場合はExceptionですか？

user=> (def f (future (Thread/sleep 10000) (throw (Exception. "hello world")))) 
#'user/f 

user=> (.get f) 
Exception hello world user/fn--318 (NO_SOURCE_FILE:81) 

user=> (.printStackTrace *e) 
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.Exception: hello world 
    at clojure.lang.Util.runtimeException(Util.java:165) 
    at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:97) 
    at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:316) 
    at user$eval320.invoke(NO_SOURCE_FILE:82) 
    at clojure.lang.Compiler.eval(Compiler.java:6465) 
    at clojure.lang.Compiler.eval(Compiler.java:6431) 
    at clojure.core$eval.invoke(core.clj:2795) 
    at clojure.main$repl$read_eval_print__5967.invoke(main.clj:244) 
    at clojure.main$repl$fn__5972.invoke(main.clj:265) 
    at clojure.main$repl.doInvoke(main.clj:265) 
    at clojure.lang.RestFn.invoke(RestFn.java:421) 
    at clojure.main$repl_opt.invoke(main.clj:331) 
    at clojure.main$main.doInvoke(main.clj:427) 
    at clojure.lang.RestFn.invoke(RestFn.java:397) 
    at clojure.lang.Var.invoke(Var.java:397) 
    at clojure.lang.AFn.applyToHelper(AFn.java:159) 
    at clojure.lang.Var.applyTo(Var.java:518) 
    at clojure.main.main(main.java:37) 
Caused by: java.util.concurrent.ExecutionException: java.lang.Exception: hello world 
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) 
    at java.util.concurrent.FutureTask.get(FutureTask.java:83) 
    at clojure.core$future_call$reify__5684.get(core.clj:6064) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
    at java.lang.reflect.Method.invoke(Method.java:597) 
    at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:92) 
    ... 16 more 
Caused by: java.lang.Exception: hello world 
    at user$fn__318.invoke(NO_SOURCE_FILE:81) 
nil 
    at clojure.core$binding_conveyor_fn$fn__3713.invoke(core.clj:1817) 
    at clojure.lang.AFn.call(AFn.java:18) 
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
    at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
    at java.lang.Thread.run(Thread.java:680) 

Answer 1

は、このリンクによると、私はClojureのがスローされることがあり、そのいずれかをキャッチし、それをラップ引き受けるので、Clojureのは、チェック例外をスローしないようだ。 http://dev.clojure.org/display/doc/1.3

慣用的にそれを処理するためとして、Javaで、その後、（？）古いルールが適用されます。私は、ExecutionExceptionにラップされた例外が、私が期待されるチェック例外の1つであるかどうかをチェックし、他の状況（読んだ場合：そうでなければコンパイラはtry catchを実施する）をエミュレートします。それがなかったら、私はランタイムの例外でそれを包んで、それをもう一度投げるか、またはそれを記録し、状況に応じてそれを飲み込むだろう。

Answer 2

ExcecutionExceptionが実際にスローされることに注意してください - それは例外がキャッチされ、Clojureので取り扱わなっていることだけです。

Clojureは、処理時にRuntimeExceptionにいくつかの例外をラップします.Clojureは、Clojureソースコードでチェック例外を処理する必要性を避けるために実行されると思います。

基本的な例外にアクセスする場合は、(.getCause e)が動作するはずです。