Clojure Q&A - Recent questions and answers in Errors

Answered: "Nested" vs "lateral" exception causes

Sun, 05 Apr 2026 21:46:32 +0000

I'm not sure this problem is common enough to warrant solving in core or extending the existing ex-info. If you are trying to throw a map bundling multiple exceptions, this really seems like a data problem more than an exception problem, and we have plenty of ways to bundle data into the ex map.

In Java, the typical solution for (one) lateral exception is to use ExecutionException, doesn't handle multiple though.

`(even? (range))` hangs

Sun, 08 Jun 2025 11:54:29 +0000

It is, of course, an error to call (even? (range)), but still - I'd much rather prefer a class cast exception. Or the existing IllegalArgumentException, just without printing the argument. Especially given that the argument could be absolutely anything, including side-effecting lazy collections.

A couple of other cases like this:

(array-map (range))
(requiring-resolve (range))

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

Tue, 13 Feb 2024 19:08:39 +0000

This has been provided with the new Uniform qualified method syntax in Clojure 1.12.0-alpha6.

Instead of using (.a ""), use the Class/member syntax. In this case, (String/.a ""). This will either compile (indicating that the Clojure compiler found a single method that matches the provided inputs), or it will throw a syntax exception (indicating that it found either 0 matching methods or multiple matching methods).

By only using this syntax, you can be sure that you're always matching against specific methods with no reflection.

Answered: Should 'method value' error messages (wrong arity) special case for constructors?

Tue, 13 Feb 2024 01:50:21 +0000

Yes, seems like that is missing the constructor specific wording, will take a look, thanks.

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

Sat, 06 Jan 2024 18:48:09 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2824

Answered: `ClassCastException` when misplacing `nth` args

Tue, 19 Dec 2023 21:21:04 +0000

Jira ticket CLJ-2822 was created to track this issue.

Answered: Null pointer error when using filter

Sat, 16 Sep 2023 07:29:19 +0000

The title is misleading - there's no NPE here, only class cast exception.

There is a stack trace (notice how I used *e in my REPL to print the latest exception):

Clojure 1.11.1
user=> (filter zero? [:hi])
Error printing return value (ClassCastException) at clojure.lang.Numbers/isZero (Numbers.java:119).
class clojure.lang.Keyword cannot be cast to class java.lang.Number (clojure.lang.Keyword is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')
(user=> 
user=> *e
#error {
 :cause "class clojure.lang.Keyword cannot be cast to class java.lang.Number (clojure.lang.Keyword is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')"
 :via
 [{:type clojure.lang.ExceptionInfo
   :message nil
   :data #:clojure.error{:phase :print-eval-result}
   :at [clojure.main$repl$read_eval_print__9206 invoke "main.clj" 442]}
  {:type java.lang.ClassCastException
   :message "class clojure.lang.Keyword cannot be cast to class java.lang.Number (clojure.lang.Keyword is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')"
   :at [clojure.lang.Numbers isZero "Numbers.java" 119]}]
 :trace
 [[clojure.lang.Numbers isZero "Numbers.java" 119]
  [clojure.core$zero_QMARK_ invokeStatic "core.clj" 874]
  [clojure.core$zero_QMARK_ invoke "core.clj" 869]
  [clojure.core$filter$fn__5962 invoke "core.clj" 2834]
  [clojure.lang.LazySeq sval "LazySeq.java" 42]
  [clojure.lang.LazySeq seq "LazySeq.java" 51]
  [clojure.lang.RT seq "RT.java" 535]
  [clojure.core$seq__5467 invokeStatic "core.clj" 139]
  [clojure.core$print_sequential invokeStatic "core_print.clj" 53]
[...]

So it seems that either the tools that you're using with Clojure hide it from you for some reason (in which case knowing the exact steps you perform to not get a stacktrace would be helpful) or you didn't look in the right place.

And in case you mean that the stacktrace seems to be pointing away from where you call filter - that's because filter doesn't actually filter anything, it creates a lazy seq that filters things out when it's being iterated over. So the stacktrace will might not include where filter is called but will include where the resulting lazy seq is being realized.

Poor Errors when deref'ing a non-IDeref/non-Future

Mon, 03 Jul 2023 18:08:19 +0000

Problem Statement

The function clojure.core/deref throws a hard-to-decipher ClassCastException when given an object that's not an instance of clojure.lang.IDeref or java.util.concurrent.Future. In my experience on-boarding new Clojure users (at my job and in my open source projects), this comes up and can be quite confusing as it doesn't point to anything obvious in the code. Even with the stack trace, it just points to deref-future's definition (instead of a specific line within the function body), which further confuses.

Discussion

On Slack, I proposed changing the implementation of deref to be something like (cond (instance? clojure.lang.IDeref ref) ... (instance? java.util.concurrent.Future ref) ... :else (throw (IllegalArgumentException (str ref " cannot be deref'd as it is of type " (class ref) ".")).

Sean Corfield brought up that such a fix would cost performance for all non-IDeref uses of deref, which I acknowledged but find acceptable.

Repro:

user=> (def a {})
#'user/a

user=> @a
Execution error (ClassCastException) at user/eval22861 (REPL:0).
class clojure.lang.PersistentArrayMap cannot be cast to class java.util.concurrent.Future (clojure.lang.PersistentArrayMap is in unnamed module of loader 'app'; java.util.concurrent.Future is in module java.base of loader 'bootstrap')

user=> (pst)
ClassCastException class clojure.lang.PersistentArrayMap cannot be cast to class java.util.concurrent.Future (clojure.lang.PersistentArrayMap is in unnamed module of loader 'app'; java.util.concurrent.Future is in module java.base of loader 'bootstrap')
    clojure.core/deref-future (core.clj:2315)
    clojure.core/deref-future (core.clj:2315)
    clojure.core/deref (core.clj:2338)
    clojure.core/deref (core.clj:2323)
    user/eval22863 (NO_SOURCE_FILE:0)
    user/eval22863 (NO_SOURCE_FILE:-1)
    clojure.lang.Compiler.eval (Compiler.java:7194)
    clojure.lang.Compiler.eval (Compiler.java:7149)
    clojure.core/eval (core.clj:3215)
    clojure.core/eval (core.clj:3211)
    clojure.main/repl/read-eval-print--9206/fn--9209 (main.clj:437)
    clojure.main/repl/read-eval-print--9206 (main.clj:437)

Answered: Interest in beginner-friendly variant of (pst)?

Sat, 01 Jul 2023 20:09:06 +0000

There are at least two, maybe more, different problems / ideas here and it would be helpful to separate them. The ex-str / hook idea seems orthogonal.

Serious question - if the error messages are ok (you said it was here), and the tooling never shows the stack trace, why is this a beginner issue? Error messages try to show a good location for the source error (to the degree that they can given macros).

"Beginner-friendly" is, I think, not the right framing as it does not say anything about the problem. Seems like if a stack trace could be more illuminating, then it would be useful to both beginners and non-beginners, and we would be helped by concretely listing challenges in understanding stack traces. Off the top of my head...

Clojure function invocation often involves 2 or 3 frames per invocation
Anonymous functions have obscure names
Anonymous functions are implicitly created in some cases by the implementation
User calls macros, but stack traces deal in the expanded code (the code you write != the code you run) - this is a fundamental problem for both error messages and stack traces
Macro code often creates gensym names that become class names
REPL infrastructure is in the stack
Tooling infrastructure is in the stack (printers, nrepl, middleware)
Mixture of Clojure core lib and Clojure Java impl
Stack traces redundantly show file name in addition to Clojure ns or Java class
Line numbers don't correlate to source correctly
Laziness effects

A "simplified stack trace" function would need to be clear about which of these or other potential problems were actually important. Some of these are pretty straightforward, some are quite hard.

Keep in mind that showing an alternate view of reality will always be in tension with the risk of hiding the actual information that illuminates why you're looking at a stack trace in the first place.

If a simplified stack printer function is useful, then this can be done independent of core. Dev tooling in particular is in a great position to augment here.

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

Wed, 14 Dec 2022 22:42:13 +0000

Comparing vectors will compare the elements in each index. For the example you have, the second elements are a number and a vector. The default comparator (which is the compare function) is not a universal comparator - there is no defined comparison between a number and a vector. So you will get a ClassCastException trying to compare them.

You can use functions like sort or sort-by that also take a custom comparator. More on comparators here: https://clojure.org/guides/comparators

Answered: Error : ClassCastException

Mon, 12 Dec 2022 21:22:14 +0000

you are calling products_2 as a function, and it is a seq of maps, not a function, which is what the class cast exception there means.

a map can be invoked as a function, but a seq of maps cannot

Answered: #object[db$getnameonly 0x66908383 db$getnameonly@66908383] 1

Fri, 09 Dec 2022 17:30:09 +0000

Interestingly, what you've got there is not a error it at, it's an object (!) like it says. (:

I might write it like this, given the shape you've provided:

user> (def customers '([1 ("John Smith" "123 Here Street" "456-4567")]
                       [2 ("Sue Jones" "43 Rose Court Street" "345-7867")]
                       [3 ("Fan Yuhong" "165 Happy Lane""345-4533")]))
#'user/customers
user> customers
([1 ("John Smith" "123 Here Street" "456-4567")]
 [2 ("Sue Jones" "43 Rose Court Street" "345-7867")]
 [3 ("Fan Yuhong" "165 Happy Lane" "345-4533")])
user> (defn id->name
        [customers id]
        (->> (filter #(= id (first %)) customers)
             (first)
             (second)
             (first)))
#'user/id->name
user> (id->name customers 3)
"Fan Yuhong"
user> (id->name customers 2)
"Sue Jones"
user> (id->name customers 1)
"John Smith"

Best of luck with your assignment!

Answered: problem with intersection

Sun, 04 Dec 2022 15:34:22 +0000

The problem is that clojure.set/intersection is defined as:

Return a set that is the intersection of the input sets

That is, it assumes that all of the arguments that you pass in are sets. Which is not your case. You are passing in vectors. Given that the input arguments do not respect the pre-conditions of the function contract, all bets are off with respect to its behaviour.

In fact, your first version also throws the same exception if the second vector doesn't contain any value that is also present in the first one:

user=> (apply set/intersection [[1 2 3] [4]])
Execution error (ClassCastException) at user/eval2082 (REPL:1). class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentSet

As you can see, it only "works" in a very limited sub-set of scenarios (and by pure chance) when not using sets for the arguments. On the other hand, using sets works as expected:

user=> (apply set/intersection [#{1 2 3} #{4}])
#{}
user=> (apply set/intersection [#{1 2 3} #{1}])
#{1}
user=> (apply set/intersection [#{\f \o} #{\o}])
#{\o}
user=> (apply set/intersection [#{\f \o} #{\a}])
#{}

Answered: clojure.stacktrace/print-throwable fails if ex-data is unprintable

Wed, 09 Nov 2022 00:07:14 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2736

Answered: Why i get "No suitable driver found for jdbc:://127.0.0.1/" ?

Mon, 26 Sep 2022 22:05:12 +0000

You're using the old clojure.java.jdbc format of db-spec hash map instead of the (simpler) next.jdbc format.

You want to remove :classname, :subprotocol, and :subname and use :dbtype "postgresql" :dbname "reporting" instead.

That simpler format works with clojure.java.jdbc too -- and is the recommended approach there too. The format you are using is really a legacy format that hasn't been recommended for a while.

Answered: Whenever I start a project, an error occurs :main namespace specified in project.clj?

Fri, 17 Jun 2022 16:43:55 +0000

You need to tell lein which namespace has the -main function that you want to run: probably clojure-noob.core. You might think your program has only 1 namespace, but in fact it will have several, including for example clojure.core, clojure.repl, clojure.main, etc., in addition to whatever your project contains.

The command lein help run will give instructions on how to specify the ns to run.

Answered: Can the "Key must be integer" error message be improved?

Wed, 25 May 2022 12:25:42 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2710

Answered: clojure.data/diff or clojure.set/difference return unexpected results

Thu, 12 May 2022 19:10:14 +0000

Solved, my problem was that I get data from datomic so I need to coerce into schema and after do the diff with this resultant set

(->> all-results
         map #(schema/coerce! % models.schema/Result))
         set)

Answered: command works on Linux but fails on Windows

Tue, 28 Dec 2021 19:25:09 +0000

Windows cmd.exe and Powershell both require different quoting to Linux/macOS.

Try either double or triple " around the version instead of single "

(according to the 2020 "State of Clojure" survey, only about 5% of Clojure users are on Windows with cmd or PS, 5% use Windows with WSL2 and therefore run Clojure stuff on Linux, and 90% use macOS or Linux -- which is why you'll often find instructions/tutorials that do not work as-is on Windows cmd/PS)

Answered: Exception in thread "main" java.lang.RuntimeException: Unable to find static field:

Tue, 30 Nov 2021 14:11:05 +0000

Well, I don't know anything about this project, but it's saying that in edu/upc/nlp4bpm_commons/Freeling.clj (which is under nlp4bpm_commons/src/main/clojure/ in the repo), that Clojure code refers to a static field AnalysisLevel/IDENT in class edu.upc.Jfreeling.AnalysisLevel and finding that that field doesn't exist.

AnalysisLevel is a class in the Java jar local-jars/Jfreeling.jar. which does have that class with that field, so if I had to guess, maybe there was a missed step in that (pretty weird) install procedure?

Answered: Some CompilerExceptions lack the file path, only having the file name

Mon, 29 Nov 2021 16:58:38 +0000

Generally, execution exceptions can occur anywhere (not just in Clojure code) and we rely more on the stack trace to identify locations for those with (pst *e). For things like compilation/macroexpansion checks those are definitely in Clojure code so they're handled differently.

Answered: make use of deprecated namespaces/vars easier to spot

Mon, 25 Oct 2021 13:24:01 +0000

Would be great to see this in the next clojure version.

Answered: Improve error messages from `reify` forms

Thu, 07 Oct 2021 15:53:35 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2661

Answered: Literal set with duplicate values reports error with wrong line number

Thu, 22 Apr 2021 18:06:53 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2624

Answered: Stacktraces with clojure functions contain irrelevant information

Thu, 15 Apr 2021 05:09:12 +0000

Per Kevin's comment, I do really want to see the actual stack trace so I don't think that should go away. But it's also useful to think about tools that can be applied to stack traces to give you better insight. That said, a lot of people have poured time into this and the results are not (imo) better than the original. I say that not to throw water on it, but just to note that it seems easy but the details are complicated.

I should mention that you happen to have chosen a scenario that is tickling a known bug in load https://clojure.atlassian.net/browse/CLJ-2529 where the phase is being incorrectly reported (here reached from a top-level form eval). While this is obviously possible, you would more typically have gotten this by having no top-level call of bar and putting this code in a namespace:

(ns repro)

(defn foo []
  (/ 1 0))

(defn bar []
  (foo))

and then put repro in your sources and called:

% clj
Clojure 1.10.3
user=> (require 'repro)
nil
user=> (repro/bar)
Execution error (ArithmeticException) at repro/foo (repro.clj:4).
Divide by zero

I think you should also note that Clojure provides a function to print stack traces (pst) that does some level of clean up for you (in some cases it will even elide top-level frames involved in the error reporting as well - that was tweaked in 1.10.0 to improve a number of cases):

user=> (pst *e)
ArithmeticException Divide by zero
	clojure.lang.Numbers.divide (Numbers.java:188)
	clojure.lang.Numbers.divide (Numbers.java:3901)
	repro/foo (repro.clj:4)
	repro/foo (repro.clj:3)
	repro/bar (repro.clj:7)
	repro/bar (repro.clj:6)
	user/eval150 (NO_SOURCE_FILE:1)
	user/eval150 (NO_SOURCE_FILE:1)
	clojure.lang.Compiler.eval (Compiler.java:7181)
	clojure.lang.Compiler.eval (Compiler.java:7136)
	clojure.core/eval (core.clj:3202)
	clojure.core/eval (core.clj:3198)

Since this is a "printing" method, it might be a place where we could do more to help, like merging invoke frames. Detecting that these are the same frame might be challenging, I don't know. The tools for emitting line/col debug symbols in bytecode are weird and I don't think that stuff has been touched in forever, there may even be options we could use that didn't exist originally. (Look for visitSource and visitLineNumber in the Compiler and the source debug extension stuff like https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L4326-L4340 - see JSR 45 for that).

I believe JRuby has spent a lot of time on this same problem (showing you a ruby stack trace that came from a jruby jvm stack trace), that might be an interesting thing to learn more about (I have not studied it).

Answered: Support for suppressed exceptions

Tue, 30 Mar 2021 17:09:32 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2618

Answered: signal an error on mulimethod without a dispatch function?

Fri, 30 Oct 2020 17:16:37 +0000

Covered by existing spec enhancement https://clojure.atlassian.net/browse/CLJ-2416

Answered: Improve error messages for clojure.core/case

Fri, 25 Sep 2020 19:21:27 +0000

Fixed in 1.10.2-alpha2

Answered: case has incorrect + difficult-to-comprehend behavior matching 'quote on Clojure 1.10.0

Sun, 26 Jul 2020 21:32:28 +0000

This is the expected behavior per the docstring, not a bug.
'foo => (quote foo)
That happens in the reader and per the case docstring you can have (constant constant constant...) so this is the pair of constant symbols quote and foo.

That's why your case on the (evaluated) expression 'quote matches 'face because it's the pair of constant expressions quote and face.

Similarly, (symbol quote) is the pair of constant expressions symbol and quote (and, again, your test expression matches.

From the docstring: "The test-constants are not evaluated. They must be compile-time literals, and need not be quoted."

In case it is not clear from that, the reason 'quote is not legal is because the reader expands that to (quote quote) and now you have a duplicate constant expression.

Answered: Calling deref on "clojure.core/clojure-version" yields "Unbound: #'clojure.core/clojure-version"

Tue, 23 Jun 2020 21:47:03 +0000

It sounds like Clojure itself has not been initialized on the path through your Java code to get to the above. That would also explain the IllegalStateException from trying to use requiring-resolve -- and you'll see that error from anything you try to reference.

Without knowing more about how you built your Java program, it's hard to say what might cause this.

Taking a look at this small repo might help you: https://github.com/stuarthalloway/clojure-from-java

Answered: How to display better errors in clojure stacktraces? is this planned to be attacked on a new clojure version?

Sun, 17 May 2020 20:49:34 +0000

Here's another +1 for even better error message out of the box.

The libraries mentioned below are treating the symptoms more or less successfully, but let's look at it from the point of someone wanting to learn Clojure, hence heads to Clojure.org, clicks on Getting Started.

Ok, I now know how to download it. Maybe I'll try to get a feel for it by using repl.it.
Now I have the bare bones experience (with the - according to clojure.org confusing error messages) (see : "One confusing error you might see is the result of accidentally trying to evaluate a list of data as if it were code:" )

Well, let's go to Learn Clojure first.
Ok, still nothing about how to launch a REPL.
Third link: Good idea to start a REPL.
Fourth link: Here are the n ways to start a REPL.
Here are other ways to run a REPL.

None mention anything about: If you are a beginner, let's add clj-stacktrace, then start a REPL.
Do you see why this is impractical?

I know you have put a lot of effort into better docs in recent years and I feel bad pointing out these things. It is hard coming back to something so familiar and look at it through the eyes of a developer who wants to learn about this new language.

I believe you have 1 or maybe 2 shots at making a good impressions and readable error messages that tell you where you went wrong is an important part of that.

user=> (map 1 inc)
Don't know how to create ISeq from: clojure.core$inc:

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

Both don't tell me what I did wrong. It tells me some specifics of how the lisp evaluator works behind the scenes. (some of them are documented on clojure.org).

Since none of this is helpful for me, the new user, I'm going to google it.
The tolerance for googling error messages for errors like wrong argument order or invoking something that can't be invoked, is not very high for beginners.

That is where you leave the impression that error messages guiding the user are not important.
(btw, curiously, you are already handing (nil 2 3) pretty good and not throwing an NPE)

This is where clojure (the implementation) actively contributes to the 'huge learning curve' meme.
It doesn't matter that - after seeing this error often enough - I learned what it is. (with regards to Sean's comment).

The damage is done.

Other Clojure dialects are doing a better job here. (CLJS and Sci, for example).

Speaking of effort: There's an objection that providing better error messages would impact performance. If we are talking about exception handling here (and in both cases above we do),
I'm not sure I understand where the performance impact is.
Exception handling because an s-expr fails is not on the performance-critical path, I would think.
Happy to better understand where the performance aspect comes into play.

Also, just for the two sample error messages above, the effort to write them from the perspective of the user - not the system - is not very high. For one of them it means changing line 557 in RT.java

Better error messages might mean catching lower-level exceptions, associating them with the current AST and re-throwing them with a message associated with the list element that generated the error.

I would implore you to guide beginners to the very best REPL they can get.
Make that the default in Getting Started and Learning Clojure.
Then you can draw back the curtain and say: Ya know, underneath is IFn and ISeq and you might see Java stacktraces.

There are so many new concepts to learn and understand when going down the Clojure path. Re-interpreting error messages shouldn't be one of them.

Answered: Namespace.java: addAlias exception could be more informative

Thu, 10 Oct 2019 16:54:31 +0000

Example? Proposed change?

Answered: ex-str can be misleading when handling s/explain-data

Fri, 02 Aug 2019 15:36:46 +0000

What's happening here is that you are accidentally creating the same exception object pattern that spec creates when there is a function spec failure during instrumentation (specifically a root cause ex-info whose ex-data is spec explain data). This is handled as a special case in the error printer.

A workaround would be to avoid that pattern, for example by moving that data out of the root:

(ex-info "Data validation failed" {:invalid (s/explain-data int? :a)})

I will think more about whether we can be more choosy about when this case is triggered in the error printer.

Answered: How do I get a full stack trace instead of "... 12 more"?

Fri, 26 Jul 2019 20:01:11 +0000

In this particular case, Leiningen is invoking clojure.main as a process and it's the subprocess JVM that is printing the (uncaught) error.

You see two exceptions here - the thrown exception, then a nested cause exception. Java's exception printer will print the "... 12 more" for nested cause stacks when they are the same as the stack already printed in the exception higher in the chain. That is, the 12 more here are exactly the same stack trace lines already printed for the first exception. So, there actually is no more info to be had here - you already have it all.

The key line here is the top line of the bottom-most (root) exception:

at xinova.model$reload_dbs.invokeStatic(model.clj:78)

I don't know what the error is, but I'd guess it's likely there is a Java interop call being made on a nil reference. This is happening while loading the file.

In Clojure 1.10.1, we have modified how uncaught exceptions going through clojure.main are reported. If you switch to that, you'll actually see just the exception message and a longer report that gets dumped to a temp file.

As an aside, The top line message you see here is "Exception in thread "main" Syntax error compiling" - that's actually misleading due to a subtle bug in the exception handling overhaul done in Clojure 1.10. I prepped a ticket and a patch for that earlier this week to fix it in Clojure 1.11 (see CLJ-2529). Basically errors happening in load are mistakenly being reported as compiler exceptions. Doesn't change things too much, but this is an example.

Answered: clojure.test/is + thrown-with-msg? error when caught exception message is nil