Clojure Q&A - Recent questions tagged exceptions

"Nested" vs "lateral" exception causes

Sun, 05 Apr 2026 14:18:26 +0000

Currently, clojure.core/ex-info must take a msg and data map, and may take a cause, which must be another Throwable, which may have its own cause, etc. etc..

This supports the case of "nested" exceptions quite well, e.g. in the case of compilation exceptions being caused by macroexpansion exceptions, potentially with their own cause, and works well for fail-on-first-problem situations.

There's also the situation of "lateral" exceptions, e.g. in the case of test runners or static analysers, which is not supported. In this case, if we take lazytest as a concrete example, the test runner throws an exception if any of the test cases it runs throws an exception, but the overall cause of the overall exception, conceptually, is all the individual exceptions.

Currently, the only to do this is to make some bespoke thing in the data map.

I propose changing clojure.core/ex-info to take [msg map & causes], which would be a non-breaking change (or, while we're at it, make the map arg optional as well and default it to {}, but that's a separate topic).

That leaves the question of how to handle ex-cause. To my understanding, to change it to return the cause or the list of causes, would maybe be a breaking change for general exception handling libraries or something, but would not imo pose any significant problem. Alternatively, we might have ex-causes to always return a list, and change ex-cause to (comp first ex-causes).

Any thoughts? I don't trust myself to spearhead a PR alone on this but I'd love to contribute, certainly the pure-clojure side of things seems straightforward enough (and I'd love to patch this into lazytest, but that's again a different topic).

Skip stacktrace creation in ExceptionInfo

Thu, 17 Jul 2025 14:46:52 +0000

Many libraries and applications use exceptions as control flow or data collection, which allows for handling complex situations with more consistent and legible code. Some libraries use custom throwables (IGJoshua/farolero, NoahTheDuke/lazytest) and some use ExceptionInfos (scgilardi/slingshot, fmnoise/flow, pangloss/pure-conditioning, exoscale/ex).

One of the reasons that libraries reach for custom throwables is because they want to skip creation of a stack trace (which isn't used and would be thrown away immediately). Stack traces in Java are already fairly expensive to create, and then the filtering work done in ExceptionInfo greatly increases that expense, making them much slower than needed. (There's an Ask about this but I can't find it.) This performance cost pressures developers to use custom throwables if their code will ever be used in a "hot path", which harms portability and ease of development. (I want to write Clojure, not Java, and I want it to be usable in Clojurescript and Babashka and whatever other dialects might arise.)

I know that there's a rejected Jira ticket (CLJ-2423) for supporting the "enableSuppression" flag, but in light of these use-cases, I'd like to bring it up again.

Cannot invoke "clojure.lang.Var.isBound()" because "clojure.lang.Compiler.LOADER" is null, potential bug?

Thu, 18 Apr 2024 16:11:35 +0000

As per discussion on slack I'm posting here the findings regarding clojure.lang.Compiler.LOADER being null during the analysis phase of GraalVM native-image run.

The full reproduction can be found here and the link to issue on Oracle GraalVM side here.

What is this issue about?

Native Image cannot be produced and throws an error during analysis phase when Clojure 1.11.2 (although the previous version of Clojure might be also affected) is used and reflection entries for java.lang.UUID and clojure.lang.Keyword are present in reflectionconfig.json.

I can't however reproduce the error prior to Clojure 1.9.0. For more information please kindly take a look into a repro.

Wrong line number reported for exceptions thrown by code generated by destructuring

Sat, 06 Jan 2024 10:56:33 +0000

Put anywhere in bad_line_number.clj, run with clj -J-Dclojure.main.report=stderr -Sdeps '{:paths ["."]}' -M -m bad-line-number from the same dir.

(ns bad-line-number)

(defn returns-a-tuple []
  [{1 2} :wrapped])

(defn should-also-return-a-tuple-but-doesnt [data]
  {data :unwrapped})

(defn -main []
  (let [[a fmt] (returns-a-tuple)
        data
        (try
          (should-also-return-a-tuple-but-doesnt a)
          (catch Throwable _
            (println "Unable to create a map")
            [3 4]))

        [x y]
        (case fmt
          :wrapped data
          :unwrapped [data nil])]
    [x y]))

Running that code results in

{:clojure.main/message
 "Execution error (UnsupportedOperationException) at bad-line-number/-main (bad_line_number.clj:10).\nnth not supported on this type: PersistentArrayMap\n",
 :clojure.main/triage
 {:clojure.error/class java.lang.UnsupportedOperationException,
  :clojure.error/line 10,
  :clojure.error/cause
  "nth not supported on this type: PersistentArrayMap",
  :clojure.error/symbol bad-line-number/-main,
  :clojure.error/source "bad_line_number.clj",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type java.lang.UnsupportedOperationException,
    :message "nth not supported on this type: PersistentArrayMap",
    :at [clojure.lang.RT nthFrom "RT.java" 992]}],
  :trace
  [[clojure.lang.RT nthFrom "RT.java" 992]
   [clojure.lang.RT nth "RT.java" 940]
   [bad_line_number$_main invokeStatic "bad_line_number.clj" 10]
   [bad_line_number$_main invoke "bad_line_number.clj" 9]
   [clojure.lang.AFn applyToHelper "AFn.java" 152]
   [clojure.lang.AFn applyTo "AFn.java" 144]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.core$apply invokeStatic "core.clj" 667]
   [clojure.main$main_opt invokeStatic "main.clj" 514]
   [clojure.main$main_opt invoke "main.clj" 510]
   [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]],
  :cause "nth not supported on this type: PersistentArrayMap"}}

Execution error (UnsupportedOperationException) at bad-line-number/-main (bad_line_number.clj:10).
nth not supported on this type: PersistentArrayMap

As you can see, it refers to line 10, which has (let [[a fmt] (returns-a-tuple), so naturally the first line of thinking is "returns-a-tuple somehow returns a map, and that's what I need to investigate".
Just spent a few hours chasing that goose when it's actually should-also-return-a-tuple-but-doesnt that's to blame.

Add type hints to `ex-info`

Tue, 24 Oct 2023 14:01:21 +0000

Sometimes I need to interact with the base exception information on an ExceptionInfo (such as .setStackTrace). The core function ex-info doesn't type hint either arity, so to avoid reflection warnings, I must specify ^ExceptionInfo when using the results of the call:

(let [old-ex (Exception. "asdf")
      new-ex (ex-info "example" {})]
  (doto  ^ExceptionInfo new-ex (.setStackTrace (.getStackTrace old-ex))))

Adding type hints to ex-info would neatly solve this for all such uses (including the uses in Clojure core, ex-data etc).

I can create a patch if there's interest.

How can tools better detect errors coming from non-existing methods/fields?

Thu, 28 Sep 2023 09:43:19 +0000

(.a ""), rightfully, throws an IllegalArgumentException without a :phase.

One can consider, however, that this IllegalArgumentException is "compiler-like", while it doesn't seem primarily distinguishable of other IllegalArgumentExceptions that may be thrown in more "runtime-like" situations.

My problem is that, as a tool maker, without such a distinction, all IllegalArgumentExceptions will be given the same treatment, while users would want a more concise treatment (e.g. no stacktraces shown) for compiler-like ones.

Is there a recommended way to inspect runtime exceptions for determining if they represent something that, from the user point of view, represents "code that is invalid to begin with"?
- (this is an informal term to describe runtime exceptions that are compiler-like)
Has it been considered to make this easier by e.g. attaching a :cause (or :phase, :ex-data, something) when the Clojure compiler/runtime can reliably do so?

Interest in beginner-friendly variant of (pst)?

Sat, 01 Jul 2023 19:19:33 +0000

Another State of Clojure survey and "error messages" is still the number one priority for improvement.

A discussion on Slack led to a number of specific pain points for beginners around exceptions and error messages. The one I'd like to focus on here is to provide a beginner-friendly alternative to (pst).

Currently, (pst) makes a reasonable attempt at demunging names, eliminating "noise", and shrinking the stack trace some -- but it still leaves a lot to be desired for beginners who struggle to understand certain exceptions and have difficulty navigating (Java-style) stack traces, especially compared to some other languages that make a big effort to provide user-friendly error messages and stack traces.

An example from Slack was:

(defn f [i]
  (fn [j]
    (/ j i)))

(run! #(% 1) (map f (range 3)))

The exception printed in the REPL is fine but (pst) shows:

user=> (pst)
ArithmeticException Divide by zero
        clojure.lang.Numbers.divide (Numbers.java:190)
        user/f/fn--16571 (NO_SOURCE_FILE:3)
        user/eval16576/fn--16577 (NO_SOURCE_FILE:1)
        clojure.core/run!/fn--8906 (core.clj:7849)
...

The elided part mentions clojure.lang.ArrayChunk.reduce and then has multiple references to clojure.core.protocols stuff (and doesn't go deep enough by default to show the original call to clojure.core/run!).

I think there's an opportunity here for a new clojure.repl/explain function, taking the same arguments as pst, that provides both a more detailed explanation of the failure and further reduces the noise in the stack trace that pst currently displays.

Ideally, this could be implemented with some basic cleanup in core but with some dynamic hooks that allow other tooling to "install" additional expansion and/or cleanup so that the community can provide libraries and functionality that further improve this aspect of the beginner experience.

A dynamic hook into ex-str, for example, would allow community-provided tooling to massage the exception message shown (both for the original REPL input and for both pst and explain) so that messages that beginners struggle with, such as class <whatever> cannot be cast to clojure.lang.IFn... could be rewritten into beginner-friendly language (Expected a function - found a <whatever>).

Similar dynamic hooks to filter stack frames, and to "print" them to strings, would allow much more friendly output for beginners.

Vector comparisons raise "clojure.lang.PersistentVector cannot be cast to java.lang.Number" exception

Wed, 14 Dec 2022 21:45:25 +0000

Hi, when I try to compare certain vectors, I get the above-mentioned error message. I tried in Clojure 1.10.3 and babashka v1.0.168.
These are some of the offending vectors:

(compare [[1] [2 3 4]], [[1] 4])
 ;=> Execution error (ClassCastException) at user/eval1 (REPL:1). 
 ;class java.lang.Long cannot be cast to class clojure.lang.IPersistentVector (java.lang.Long is in module java.base of loader 'bootstrap'; clojure.lang.IPersistentVector is in unnamed module of loader 'app')

(compare [[[1 4 []] [6 2] 6 7 6] [[[10 4]] [10] [[3 5 1 9] 3 1 [7 5] 8] 2] [1 [2 [0 3] [2 10 2] 2] [[2 9 7 8 0] [6 0] 10] 9] [[[8 5 8 3]] 2 [2 3 [7 8]]] [0]]
         [[[[3] 4 4] 10 5 2 []] [7 8] [7 7 [[]]] [] [[[4 10 6 7]] [9] [] 3]])

Is this a bug, or am I just blind as to why this is obviously expected behavior?

I came across this while doing one of the Advent of Code programming exercises yesterday. It asks you to compare a number of vectors, see https://adventofcode.com/2022/day/13

I did solve the exercise by implementing my own vector comparator, according to the specifications given in the exercise. I uploaded the source code in case you want it for testing purposes: https://github.com/eNotchy/Advent-of-Code-2022/tree/main/Day13

Throw an error in cljc code

Sun, 04 Apr 2021 14:55:01 +0000

I'm writing a cljc library that needs to throw an error. This is how I tried to do it:

(def ErrorType #?(:clj java.lang.Exception
                  :cljc js/Error)

(throw (new ErrorType "message"))

But this code fails with an error saying "couldn't find class ErrorType". What is the correct way of doing this?

Support for suppressed exceptions

Tue, 30 Mar 2021 12:08:05 +0000

Java 7 try-with-resources makes sure no exceptions are lost in case close throws while another exception is already bubbling from the block's body. This is done by attaching the latter exception to the former as suppressed. Suppressed exceptions are made visible in printStackTrace making it easier to diagnose complex problems involving multiple failures.

It seems with-open doesn't record suppressed exceptions. close-ing is handled in the finally block, and if the stack has been already unwinding any exceptions thrown by close will override.

On top of that, clojure.stacktrace seems to ignore the existence of suppressed exceptions entirely.

Is there a reason not to support suppressed exceptions? Or is this just a legacy of pre-Java-7 implementation? Would you consider adding the support in?

Here's one implementation of with-open supporting suppression: https://gist.github.com/mszajna/0ccbdfbd10927ff5d9517aaeb319952a
It forgoes of the finally block, closing the resource outside the try block in the happy case. In the unhappy case, the catch block does the suppression recording and makes sure the original exception propagates up.

I can imagine another implementation could make use of piece of state to record original exception and keep the finally block perhaps.

I don't have a proposal for clojure.stacktrace at this stage. I'm not sure whether this should be a new function or should the suppressed exceptions be included in print-cause-trace. On one hand, backward compatibility is nice, on the other, it would be great for existing tooling to take advantage of this improvement.

clojure.lang.ArityException, Wrong number of args (1) passed?

Tue, 02 Mar 2021 06:50:04 +0000

I am learning clojure, it's my 2nd day with the language, and writing some simple functions:

(defn fib_effi
[n]
(cond (= n 0) 0
      (= n 1) 1
     :else ((defn fib_iter [i fibi_n_prev fibi_n]
               (if (= i n) fibi_n
                   (fib_iter (+ i 1) fibi_n (+ fibi_n fibi_n_prev))))
             (fib_iter 1 0 1))))
(fib_effi 3)

I am getting the error message:

Unhandled clojure.lang.ArityException
Wrong number of args (1) passed to:
chapters.core/fib-effi/fib-iter--6404

Is there anything I am missing?

Namespace.java: addAlias exception could be more informative

Thu, 10 Oct 2019 15:55:01 +0000

In https://github.com/clojure/clojure/blob/653b8465845a78ef7543e0a250078eea2d56b659/src/jvm/clojure/lang/Namespace.java#L224-L225, the ns argument is not included in the exception message.

This hinders debuggabiliity, especially when the .addAlias call didn't originate from intentful aliasing, but rather, as a result of re-evaluating a namespace (which is the AST-building strategy that tools such as https://github.com/jonase/eastwood use).

Have you considered improving the message?