That Calva activates when one of its views are activated is VS Code behavior. But maybe we can stop that tab from showing unless Calva is activated…

currently I just hide the tab since I rarely use the inspector

(ex-cause *e) perhaps?

Thanks, I'll try that

I guess it depends on what exactly you mean by "In the repl in calva, I can just print out the stacktrace for the outer exception."

I should be more specific, I am running the test from the menu:

OK... I don't understand how that relates to "In the repl in calva, I can just print out the stacktrace for the outer exception."

Are you saying that the tests fail and you see an exception in their output, but only the component exception, not the cause?

Yes, thanks for translating for me.

I don't know how Calva runs tests (I don't use the Calva machinery for that -- I run tests directly via custom REPL snippets) but I would have expected the full stacktrace including the cause to be printed in one of the output windows?

An easy workaround is to put a try/catch in the start and stop functions of each component, but was hoping for a more general solution ( I can then print out the "inner" exception before re-throwing).

Sorry, I guess without seeing exactly how your code is setup and exactly what you're seeing in VS Code, I can't suggest anything specific. It's not a problem I recall running into... Are you using test fixtures? Or are you explicitly starting/stopping components in your tests?

Its ok, I have a workaround. I was hoping for a setting in calva that would change the behavior.

I do both ... depending on the test. I don't think this is component specific. I'll try to put together a little example and create an issue on the calva repo.

Well, I don't understand what "behavior" you're really talking about -- but it sounds like something inherent in how your code is behaving based on how Calva is running tests, so it's not Calva specific per se.

If this is code up on GH that shows the exception behavior when tests are run, I am happy to take a look...

Here is an actual example:

(defn foo []
  (try
    (throw (Exception. "inner"))
    (catch Exception e
      (throw (Exception. "outer" e)))))

(deftest foo-test
  (is (= 1 (foo))))

ERROR in (foo-test) (core_test.clj:109)
expected: (= 1 (foo))
  actual: java.lang.Exception: outer
 at fortune.core_test$foo.invokeStatic (core_test.clj:109)
    fortune.core_test$foo.invoke (core_test.clj:109)
    fortune.core_test$fn__25183.invokeStatic (core_test.clj:116)
    fortune.core_test/fn (core_test.clj:115)
    clojure.test$test_var$fn__9856.invoke (test.clj:717)
    clojure.test$test_var.invokeStatic (test.clj:717)
    ...
    clojure.main$main.invokeStatic (main.clj:664)
    clojure.main$main.doInvoke (main.clj:616)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.main.main (main.java:40)
Caused by: java.lang.Exception: inner
 at fortune.core_test$foo.invokeStatic (core_test.clj:109)
    fortune.core_test$foo.invoke (core_test.clj:109)
    fortune.core_test$fn__25183.invokeStatic (core_test.clj:116)
    fortune.core_test/fn (core_test.clj:115)
    clojure.test$test_var$fn__9856.invoke (test.clj:717)
    ...
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.main.main (main.java:40)

; ERROR in fortune.core-test/foo-test (core_test.clj:116):
; error: java.lang.Exception: outer (core_test.clj:116)
; expected:
(= 1 (foo))

; 1 tests finished, problems found. 😭 errors: 1, failures: 0, ns: 1, vars: 1
clj꞉fortune.core-test꞉> 
fortune.core-test/foo (core_test.clj:109)
fortune.core-test/fn (core_test.clj:116)
fortune.core-test/fn (core_test.clj:115)
cider.nrepl.middleware.test/test-var (test.clj:306)
cider.nrepl.middleware.test/test-var (test.clj:305)
cider.nrepl.middleware.test/test-var (test.clj:295)
cider.nrepl.middleware.test/test-vars (test.clj:338)
clojure.test/default-fixture (test.clj:687)
clojure.test/default-fixture (test.clj:683)
cider.nrepl.middleware.test/test-vars (test.clj:337)
clojure.lang.PersistentVector/reduce (PersistentVector.java:343)
...
nrepl.middleware.session/session-exec (session.clj:217)
java.lang.Thread/run (Thread.java:833)
clj꞉fortune.core-test꞉>

Ah, so this is likely to be a combination of CIDER middleware (which is running the tests) and possibly some additional cleanup Calva then tries to do on the nREPL result that CIDER produces...

When I run that test using the custom REPL snippet that invokes clojure.test/run-tests for the current ns, I see this output (again, edited for clarity):

ERROR in (foo-test) (NO_SOURCE_FILE:72)
expected: (= 1 (foo))
  actual: java.lang.Exception: outer
 at ws.example_test$foo.invokeStatic (NO_SOURCE_FILE:72)
...
Caused by: java.lang.Exception: inner
 at ws.example_test$foo.invokeStatic (NO_SOURCE_FILE:72)
...

I recommend setting up one or more custom repl snippets that runs the test. Then, even if your regular workflow involves the cider-nrepl test runner, you can invoke the snippets to have a look at stack traces that may get lost in the middleware.

Thanks for the ideas.