Clojure Q&A - Recent questions in Errors

"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).

`(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))

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

Mon, 12 Feb 2024 23:36:52 +0000

If I call a method with the wrong number of arguments, I get a concise, descriptive error message:
(^[] String/toUpperCase "foo" 2) Syntax error... Invocation of method toUpperCase in class java.lang.String expected 0 arguments, but received 1

If I call a constructor with the wrong number of arguments, I get a very similar message:
(^[String] String/new "foo" 2) Syntax error... Invocation of method java.lang.String in class java.lang.String expected 1 arguments, but received 2

This message refers to the class name as the method, which feels like what you might get for a constructor.

I noticed that if my param-tags are incorrect on a constructor, the wording of the message is slightly different ("Expected to find 1 matching signature for constructor" as opposed to "for method"), so I just want to pose the question while these messages are somewhat fresh: Should the wording for the arity message mention 'constructor' or 'String/new' or something along those lines?

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.

`ClassCastException` when misplacing `nth` args

Mon, 11 Dec 2023 05:42:28 +0000

I accidentally misplaced the args to nth and was presented with the following error and stacktrace:

  Show: Project-Only All 
  Hide: Clojure Java REPL Tooling Duplicates  (0 frames hidden)

2. Unhandled clojure.lang.Compiler$CompilerException
   Error compiling NO_SOURCE_FILE at (79:3)
   #:clojure.error{:phase :execution,
                   :line 79,
                   :column 3,
                   :source "NO_SOURCE_FILE"}
             Compiler.java: 3719  clojure.lang.Compiler$InvokeExpr/eval
             Compiler.java:  457  clojure.lang.Compiler$DefExpr/eval
             Compiler.java: 7199  clojure.lang.Compiler/eval
             Compiler.java: 7149  clojure.lang.Compiler/eval
                  core.clj: 3215  clojure.core/eval
                  core.clj: 3211  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj: 1990  clojure.core/with-bindings*
                  core.clj: 1990  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  829  java.lang.Thread/run

1. Caused by java.lang.ClassCastException
   class clojure.lang.PersistentVector cannot be cast to class
   java.lang.Number (clojure.lang.PersistentVector is in unnamed module of
   loader 'app'; java.lang.Number is in module java.base of loader
   'bootstrap')

                      REPL:   82  advent-of-clerk.year-2023.day-04/fn
                      REPL:   79  advent-of-clerk.year-2023.day-04/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
             Compiler.java: 3714  clojure.lang.Compiler$InvokeExpr/eval
             Compiler.java:  457  clojure.lang.Compiler$DefExpr/eval
             Compiler.java: 7199  clojure.lang.Compiler/eval
             Compiler.java: 7149  clojure.lang.Compiler/eval
                  core.clj: 3215  clojure.core/eval
                  core.clj: 3211  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj: 1990  clojure.core/with-bindings*
                  core.clj: 1990  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  829  java.lang.Thread/run

I was having a hard time spotting the problem, as I was changing a few things at once. Ultimately I realized that I've misplaced the collection and the index arguments to nth, but the stacktrace did little to help me realize that: there is no mention of call to nth there, and the line numbers are not pointing exactly to the problematic line.

The complete example code here: https://github.com/a1exsh/advent-of-clerk/blob/cddd42fcd60da2efcda37f222666328cd37fb616/src/advent_of_clerk/year_2023/day_04.clj#L84 (this is the correct code — to get the error swap the arguments like this: (nth i untouched))

The environment where I was hitting this is evaluating the single loop form in CIDER (Emacs) with C-x C-e.

It can be readily reproduced in REPL of course, just like this:

user> (nth 0 [])
Execution error (ClassCastException) at user/eval22783 (REPL:42).
class clojure.lang.PersistentVector cannot be cast to class java.lang.Number (clojure.lang.PersistentVector is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')

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?

Null pointer error when using filter

Sat, 16 Sep 2023 07:09:30 +0000

Bumped into this quirk when repling around today: (filter zero? [:hi]) throws a java.lang.ClassCastException without a proper stack trace.

I am using Clojure version 1.11.1.1347 .

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)

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

Error : ClassCastException

Sun, 11 Dec 2022 05:53:56 +0000

Hi!

I have an error in my console that points to my function :

 (defn sales-by-customer [name-cus]
   (->> sales_2
       (filter #(= (second %) name-cus))
       (map #(* (Integer/parseInt (last %)) (Double. (products_2 (second %)))))
       (reduce +)
    )
  )

sales_2 : [id customers_name products_name quantity]

([1 Sara candies 3] 
 [2 Joe jam 3]
 [3 Sara gum 1])

products_2 : {products_name price}

({candies 6.0} {gum 4.5} {jam 45.1})

Basically, what I'm trying to do is, when I call (sales-by-customer "Sara"), I want to get the sum of Sara's purchases, which is in this case : (36.0 + 14.5) and display the result.

When I call my function, I get the following error message :

 Syntax error (ClassCastException) compiling at (db.clj:76:1).
class clojure.lang.LazySeq cannot be cast to class clojure.lang.IFn (clojure.lang.LazySeq and clojure.lang.IFn are in unnamed module of loader 'app')

Any idea how to solve this error?
I'm supposed to get a number.. I don't know where the cast error occurs...

Thanks!

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

Fri, 09 Dec 2022 06:35:16 +0000

Hi!
I've been working on a script and I don't understand what this error means.

My function, takes a number (id) and extract the first element of a list in my vector.

Details :

My function :

 (defn getnameonly [number] 
  (doall (nth (
        (nth 
         (filter #(= number (first %)) customers) 
         0) 
        1) 
       0))
  )

where customers is :
(
[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)]
)

So basically, I want to pull out (return value) "John Smith" if I give 1 to my function.

The code :

(nth (
            (nth 
             (filter #(= number (first %)) customers) 
             0) 
            1) 
           0))

works fine outside the function. However, when I call :

(println getnameonly 1)

I get :

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

Any idea why and how to solve this issue?

problem with intersection

Sun, 04 Dec 2022 12:01:18 +0000

This code works:

(apply clojure.set/intersection [[1 2 2] [1]])

but this generates an exception "class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentSet":

(apply clojure.set/intersection [[\f \o \o] [\o]])

I don't understand why (I'm new too Clojure, started learning today).

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

Tue, 08 Nov 2022 23:00:53 +0000

If an exception is thrown that contains unprintable ex-data, calling print-stack-trace will fail because print-throwable will throw an exception, making it very hard to debug certain failures.

(defn print-throwable
  "Prints the class and message of a Throwable. Prints the ex-data map
  if present."
  {:added "1.1"}
  [^Throwable tr]
  (printf "%s: %s" (.getName (class tr)) (.getMessage tr))
  (when-let [info (ex-data tr)]
    (newline)
    (pr info)))

Unprintable ex-data could include a third-party record type that implements multiple interfaces that conflict for print-method but did not anticipate making the record printable.

Wrapping that (pr info) in (try .. (catch Throwable t and printing something like (str "<unprintable ex-data: " (ex-message t)">)" might be a reasonable compromise here to allow for easier debugging.

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

Mon, 26 Sep 2022 21:45:00 +0000

Java version :

openjdk 18.0.2-ea 2022-07-19
OpenJDK Runtime Environment (build 18.0.2-ea+9-Ubuntu-222.04)
OpenJDK 64-Bit Server VM (build 18.0.2-ea+9-Ubuntu-222.04, mixed mode, sharing)

but when i start the nREPL in my text editor, it's says :

Starting nREPL server...
/usr/lib/jvm/java-11-openjdk-amd64/bin/java ...

Dependencies :

:dependencies [[org.clojure/clojure "1.11.1"]
               [com.github.seancorfield/next.jdbc "1.3.834"]
               [org.postgresql/postgresql "42.5.0"]
               [com.layerware/hugsql "0.5.3"]]

code :

(def db
    {:classname "org.postgresql.Driver"
     :subprotocol "postgresql"
     :subname "reporting"
     :user "admin"
     :password "admin"})

(defn add-user-transaction [users]
  (jdbc/with-transaction [t-conn db]
                         (if-not (find-user t-conn {:id (:id users)})
                           (add-user! t-conn users))))

Everything works normal with that configuration, but only when i evaluate

(add-user-transaction {:id "cheryl"
                   :pass "Cheryl"})

the error appears.

It's asked in Clojure: Execution error (SQLException) at java.sql.DriverManager/getConnection (DriverManager.java:702) and already have answered, but the only answer in there is using :deps or deps.edn (as far i know, this is Maven repository), so how about leiningen? Or did i miss something about leiningen and Maven?
And i even restarting my pc, text editor, and nREPL but nothing change.

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

Fri, 17 Jun 2022 14:40:34 +0000

Whichever github project I run I get the same error.

Now I have started a simple example from the book clojure for brave and true and the same program appears.

(ns clojure-noob.core (:gen-class))

(defn -main "I don't do a whole lot ... yet." [& args] (println "I'm a little teapot!"))

error is > PS C:\Users\danny\New folder\cftbat-code> lein run
No :main namespace specified in project.clj.

what can i do and what i am doing wrong?

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

Wed, 25 May 2022 05:54:04 +0000

The Key must be integer error message often catches me off guard and I forget what it meant.

Could this message be improved so that it is a little more self-describing?

e.g. Tried to assoc a non-integer key to a vector.

Thanks - V

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

Thu, 12 May 2022 14:20:12 +0000

Hello folks!, I got a rare issue, where I have a 2 sets of maps and I need get the differences between both like the following example:

 first-sequence: #{{:id "test" :status :up} {:id "other" :status :up}}

second-sequence: #{{:id"test" :status :up} {:id "other" :status :up}}

So with these two sets of data I execute the following sentence

(seq (map #(produce!
            (adapt-schema %) producer)
          (first (clojure.data/diff first-sequence second-sequence))))

And I expect as result

[nil nil #{{:id "test" :status :up} {:id "other" :status :up}]

But I get in tests the following result from de diff and after I publish wrong number of messages

[#{{:id "test" :status :up} {:id "other" :status :up}#{{:id "test" :status :up} {:id "other" :status :up}nil]

But for example in the REPL I get the correct values so I'm lost with this behavior, any response will be very helpful for me. Thanks!

command works on Linux but fails on Windows

Tue, 28 Dec 2021 18:40:39 +0000

No question--just providing feedback. This command works on Linux but fails on Windows:

clojure -Ttools install io.github.seancorfield/deps-new '{:git/tag "v0.4.8"}' :as new

Here is the full error report:

{:clojure.main/message
"Execution error (ExceptionInfo) at clojure.tools.deps.alpha.extensions.git/coord-err (git.clj:45).\r\nLibrary io.github.seancorfield/deps-new has invalid tag: v0.4.8\r\n",
:clojure.main/triage
{:clojure.error/class clojure.lang.ExceptionInfo,
:clojure.error/line 45,
:clojure.error/cause
"Library io.github.seancorfield/deps-new has invalid tag: v0.4.8",
:clojure.error/symbol
clojure.tools.deps.alpha.extensions.git/coord-err,
:clojure.error/source "git.clj",
:clojure.error/phase :execution},
:clojure.main/trace
{:via
[{:type clojure.lang.ExceptionInfo,
:message
"Library io.github.seancorfield/deps-new has invalid tag: v0.4.8",
:data
{:lib io.github.seancorfield/deps-new,
 :coord
 {:git/tag v0.4.8,
  :git/sha "a059d98edcbe25d5fb5b17052b56ab31a8d4eeff"}},
:at
[clojure.tools.deps.alpha.extensions.git$coord_err
 invokeStatic
 "git.clj"
 45]}],
:trace
[[clojure.tools.deps.alpha.extensions.git$coord_err
invokeStatic
"git.clj"
45]
[clojure.tools.deps.alpha.extensions.git$coord_err
invoke
"git.clj"
43]
[clojure.tools.deps.alpha.extensions.git$eval1234$fn__1236
invoke
"git.clj"
66]
[clojure.lang.MultiFn invoke "MultiFn.java" 239]
[clojure.tools.tools.api$install invokeStatic "api.clj" 45]
[clojure.tools.tools.api$install invoke "api.clj" 20]
[clojure.lang.AFn applyToHelper "AFn.java" 154]
[clojure.lang.AFn applyTo "AFn.java" 144]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.core$apply invokeStatic "core.clj" 667]
[clojure.core$apply invoke "core.clj" 662]
[clojure.run.exec$exec invokeStatic "exec.clj" 48]
[clojure.run.exec$exec doInvoke "exec.clj" 39]
[clojure.lang.RestFn invoke "RestFn.java" 423]
[clojure.run.exec$_main$fn__205 invoke "exec.clj" 178]
[clojure.run.exec$_main invokeStatic "exec.clj" 174]
[clojure.run.exec$_main doInvoke "exec.clj" 139]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[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
"Library io.github.seancorfield/deps-new has invalid tag: v0.4.8",
:data
{:lib io.github.seancorfield/deps-new,
:coord
{:git/tag v0.4.8,
:git/sha "a059d98edcbe25d5fb5b17052b56ab31a8d4eeff"}}}}

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

Tue, 30 Nov 2021 08:45:56 +0000

Hey, i`'m still very green in clojure and Java but i want to use this git repo https://github.com/setzer22/alignment_model_text .

when i execute the Installation script i get the followign error:

 [INFO] --- clojure-maven-plugin:1.8.4:compile (clojure-compile) @ modelvsdocument ---
Compiling edu.upc.modelvsdocument.extraction.common to /home/user/alignment_model_text-master/modelvsdocument/target/classes
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/boolean?
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/boolean?
Exception in thread "main" java.lang.RuntimeException: Unable to find static field: IDENT in class edu.upc.Jfreeling.AnalysisLevel, compiling:(edu/upc/nlp4bpm_commons/Freeling.clj:51:8)
        at clojure.lang.Compiler.analyze(Compiler.java:6720)
        at clojure.lang.Compiler.analyze(Compiler.java:6657)
        at clojure.lang.Compiler$MapExpr.parse(Compiler.java:3072)
        at clojure.lang.Compiler.analyze(Compiler.java:6709)
        at clojure.lang.Compiler.analyze(Compiler.java:6657)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3767)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6921)
[...]

So i googled and tried to fix that, but i'm not really sure about the exact problem.

Does anyone know what causes such an error? And maybe have some tips to solve this?

Thank you very much!

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

Thu, 04 Nov 2021 15:32:06 +0000

Some CompilerExceptions, especially ones that are thrown by evaluating the init expression of def forms, only contain the file name, not the file path.

For example, let's say you have a file that looks like:

(ns example.core1)

(def x (throw (ex-info "error!!" {})))

And load the namespace, then you'll see the CompilerException only contains the file name, instead of the file path:

user=> (require 'example.core1)
Execution error (ExceptionInfo) at example.core1/fn (core1.clj:3).
error!!
user=> (ex-data *e)
#:clojure.error{:phase :execution, :line 3, :column 8, :source "core1.clj"}
user=>

This is in contrast to other CompilerExceptions, which do contain the file path in their ex-data. For example, let's say you have another file that looks like:

(ns example.core2)

(no-such-function)

And then:

user=> (require 'example.core2)
Syntax error compiling at (example/core2.clj:3:1).
Unable to resolve symbol: no-such-function in this context
user=> (ex-data *e)
#:clojure.error{:phase :compile-syntax-check, :line 3, :column 1, :source "example/core2.clj"}
user=>

It seems that this difference comes from the fact that a DefExpr is constructed with SOURCE passed, instead of SOURCE_PATH.

It would be nice if CompilerExceptions always contain the file path (as far as possible), since it may be hard to identify the exact location where the exception occurred from only the file name.

Improve error messages from `reify` forms

Thu, 07 Oct 2021 12:54:12 +0000

I had a syntax error in a reify form today and the error was pretty cryptic:

(defprotocol Foo
  (foo [a]))

(reify Foo
  (foo a
    (inc a)))

Produces the following error:

Syntax error (IllegalArgumentException) compiling at (REPL:1:1).
Don't know how to create ISeq from: clojure.lang.Symbol

It would be beneficial if the error message contained the word reify and foo as breadcrumbs, that would have lead me to identify the error more easily.

Also the line number of a column are incorrect - they refer to the position of the opening paren of the reify form (line 1, column 1) whereas my error is on line 2, column 7.

Thinking about a better message, something like:

> Syntax error in reify form – found symbol 'a' when expecting an argument list.

Literal set with duplicate values reports error with wrong line number

Thu, 22 Apr 2021 18:04:25 +0000

Repro:

% cat src/dupes.clj
(ns dupes
  (:gen-class))

(defn -main
  []
  (let [x 1 y 1]
    (pr-str "this is not the error you're looking for")
    ;; This is a lengthy, multi-line comment. It serves no other purpose than to put
    ;; distance between the last line to emit a line number and the line that throws the
    ;; exception
    #{x y}))

% clj -M -m dupes
Execution error (IllegalArgumentException) at dupes/-main (dupes.clj:7).
Duplicate key: 1

Reports error at line 7, but should be line 11.

Stacktraces with clojure functions contain irrelevant information

Mon, 12 Apr 2021 20:20:58 +0000

Background

I saw reddit discussion about error messages and one user's comment about signal-to-noise ratio resonated with me and got me thinking about how stack traces are presented to the user at the REPL.

Context

I had a look at various developments in this area, including:
- Stuart Holloway's opinion that stack traces are always the right length
- clj-stacktrace library
- pretty library
- clojure archive page with design iterations around stack traces, including this snippet

My thoughts on this is that existing libraries are either try to hide too much (pretty) or mostly concerned with presentation/formatting and not the actual contents (clj-stacktrace). I generally agree with Stuart that stack traces are the right length because every stack element is truth, an unambiguous description of the stack of methods that were executing when exception happened.

Scope

This discussion is about stack traces presented to programmer at the REPL, think Throwable->map and clojure.core/print-throwable, not re-wrapping all thrown exceptions.

Problem

The purpose of stack trace is to present useful information about executed methods that give context to exception. I think that one aspect that makes this information useful is ability to see/navigate to code that led to an exception. In case of functions defined in Clojure code, there are no methods/enclosing classes to see/navigate to since bytecode for those is emitted dynamically from function definitions. In addition to that, stack traces of what semantically is a single function call usually contain multiple elements where some of those elements point to a line where the function is defined, which is also not useful.

Illustration

Given a file repro.clj (I included line numbers):

1 (defn foo []
2   (/ 1 0))
3 
4 (defn bar []
5   (foo))
6 
7 (bar)

Loading this file in the REPL and showing the error will show the following stack trace:

clj
Clojure 1.10.1
user=> (load-file "repro.clj")
Syntax error (ArithmeticException) compiling at (C:\Users\Vlaaad\Projects\vlaaad.github.io\repro.clj:7:1).
Divide by zero
user=> *e
#error {
 :cause "Divide by zero"
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message "Syntax error compiling at (C:\\Users\\Vlaaad\\Projects\\vlaaad.github.io\\repro.clj:7:1)."
   :data #:clojure.error{:phase :compile-syntax-check, :line 7, :column 1, :source "C:\\Users\\Vlaaad\\Projects\\vlaaad.github.io\\repro.clj"}
   :at [clojure.lang.Compiler load "Compiler.java" 7648]}
  {:type java.lang.ArithmeticException
   :message "Divide by zero"
   :at [clojure.lang.Numbers divide "Numbers.java" 188]}]
 :trace
 [[clojure.lang.Numbers divide "Numbers.java" 188]
  [clojure.lang.Numbers divide "Numbers.java" 3901]
  [user$foo invokeStatic "repro.clj" 2]
  [user$foo invoke "repro.clj" 1]
  [user$bar invokeStatic "repro.clj" 5]
  [user$bar invoke "repro.clj" 4]
  [user$eval140 invokeStatic "repro.clj" 7]
  [user$eval140 invoke "repro.clj" 7]
  [clojure.lang.Compiler eval "Compiler.java" 7177]
  [clojure.lang.Compiler load "Compiler.java" 7636]
  [clojure.lang.Compiler loadFile "Compiler.java" 7574]
  [clojure.lang.RT$3 invoke "RT.java" 327]
  [user$eval1 invokeStatic "NO_SOURCE_FILE" 1]
  [user$eval1 invoke "NO_SOURCE_FILE" 1]
  [clojure.lang.Compiler eval "Compiler.java" 7177]
  [clojure.lang.Compiler eval "Compiler.java" 7132]
  [clojure.core$eval invokeStatic "core.clj" 3214]
  [clojure.core$eval invoke "core.clj" 3210]
  [clojure.main$repl$read_eval_print__9086$fn__9089 invoke "main.clj" 437]
  [clojure.main$repl$read_eval_print__9086 invoke "main.clj" 437]
  [clojure.main$repl$fn__9095 invoke "main.clj" 458]
  [clojure.main$repl invokeStatic "main.clj" 458]
  [clojure.main$repl_opt invokeStatic "main.clj" 522]
  [clojure.main$main invokeStatic "main.clj" 667]
  [clojure.main$main doInvoke "main.clj" 616]
  [clojure.lang.RestFn invoke "RestFn.java" 397]
  [clojure.lang.AFn applyToHelper "AFn.java" 152]
  [clojure.lang.RestFn applyTo "RestFn.java" 132]
  [clojure.lang.Var applyTo "Var.java" 705]
  [clojure.main main "main.java" 40]]}

Let's focus on the stack trace elements that belong to repro.clj:

[clojure.lang.Numbers divide "Numbers.java" 188]
[clojure.lang.Numbers divide "Numbers.java" 3901]
[user$foo invokeStatic "repro.clj" 2]
[user$foo invoke "repro.clj" 1]
[user$bar invokeStatic "repro.clj" 5]
[user$bar invoke "repro.clj" 4]
[user$eval140 invokeStatic "repro.clj" 7]
[user$eval140 invoke "repro.clj" 7]

Every Clojure function call in code has 2 corresponding stack elements: invoke and invokeStatic. Method invoke for classes user$foo and user$bar point to lines 1 and 4. If you look at the repro.clj, you'll notice these are the lines where function foo and bar are defined — this information is not useful, and generally stack traces for java code don't point to lines where methods are defined, only to lines inside the method bodies that invoke methods higher on the stack. While it is possible to use interop to call .invoke directly as this is defined in IFn, invokeStatic is a method emitted by the compiler and arguably is an implementation detail.

Possible solutions?

Do nothing

Stuart might be right — if I am debugging bytecode-related issue, I would certainly be interested in these details. Also, some future version of Clojure might emit function bytecode differently, leading to a fewer amount of more readable stack traces.

Merge stack elements

This approach merges stack elements of a same function that keeps only public invoke methods visible and reports lines that actually did the call to next method in the stack. This is a pretty minimal filtering that will make stacktrace for the repro exception look like that:

[clojure.lang.Numbers divide "Numbers.java" 188]
[clojure.lang.Numbers divide "Numbers.java" 3901]
[user$foo invoke "repro.clj" 2]
[user$bar invoke "repro.clj" 5]
[user$eval140 invoke "repro.clj" 7]
[clojure.lang.Compiler eval "Compiler.java" 7177]
[clojure.lang.Compiler load "Compiler.java" 7636]
[clojure.lang.Compiler loadFile "Compiler.java" 7574]
[clojure.lang.RT$3 invoke "RT.java" 327]
[user$eval1 invoke "NO_SOURCE_FILE" 1]
[clojure.lang.Compiler eval "Compiler.java" 7177]
[clojure.lang.Compiler eval "Compiler.java" 7132]
[clojure.core$eval invoke "core.clj" 3214]
[clojure.main$repl$read_eval_print__9086$fn__9089 invoke "main.clj" 437]
[clojure.main$repl$fn__9095 invoke "main.clj" 458]
[clojure.main$repl invoke "main.clj" 458]
[clojure.main$repl_opt invoke "main.clj" 522]
[clojure.main$main invoke "main.clj" 667]
[clojure.lang.RestFn invoke "RestFn.java" 397]
[clojure.lang.AFn applyToHelper "AFn.java" 152]
[clojure.lang.RestFn applyTo "RestFn.java" 132]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.main main "main.java" 40]

I think this already does a decent job at reducing signal-to-noise ratio, and if you debug bytecode-related issues, you can still get the full stack trace using .getStackTrace on an exception object.

Make Clojure stack elements resemble code

A part of Clojure philosophy is to prefer functions over methods, perhaps stack elements pointing to Clojure functions should look like functions and not methods? Most of the time there is no .invoke interop in code. I would prefer to act upon user/foo, not user$foo invoke, because this is something I can actually see in my code. One might argue that even stack elements like clojure.lang.AFn applyToHelper and clojure.lang.RestFn invoke are also unnecessary since they are implementation details that make any Clojure functions invokable with variadic arguments (there is some filtering of those details already!). There are many unknowns in this direction that I didn't try to answer because I'm not sure if it's worth pursuing, but here is an illustration of how stack traces might look in that case:

[clojure.lang.Numbers.divide "Numbers.java" 188]
[clojure.lang.Numbers.divide "Numbers.java" 3901]
[user/foo "repro.clj" 2]
[user/bar "repro.clj" 5]
[user/eval140 "repro.clj" 7]
[clojure.lang.Compiler.eval "Compiler.java" 7177]
[clojure.lang.Compiler.load "Compiler.java" 7636]
[clojure.lang.Compiler.loadFile "Compiler.java" 7574]
[clojure.lang.RT$3.invoke "RT.java" 327]
[user/eval1 "NO_SOURCE_FILE" 1]
[clojure.lang.Compiler.eval "Compiler.java" 7177]
[clojure.lang.Compiler.eval "Compiler.java" 7132]
[clojure.core/eval "core.clj" 3214]
[clojure.main/repl/read-eval-print--9086/fn--9089 "main.clj" 437]
[clojure.main/repl/fn--9095 "main.clj" 458]
[clojure.main/repl "main.clj" 458]
[clojure.main/repl-opt "main.clj" 522]
[clojure.main/main "main.clj" 667]
[clojure.main.main "main.java" 40]

Some open questions:
- representing Clojure function calls as single symbol instead of a pair class+method asks to represent java method calls as single symbols, how should those look like? clojure.lang.Compiler/eval vs clojure.lang.Compiler.eval vs something else?
- how to show method calls for deftypes/reifies? those are both Clojure and methods...
- are Var/AFn/RestFn stack elements truly irrelevant?

Something else

There might be other options...

What do you think?

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.

signal an error on mulimethod without a dispatch function?

Wed, 28 Oct 2020 20:09:35 +0000

user=> (defmulti thing)
#'user/thing
user=> (defmethod thing :default [x] :hi)
#object[clojure.lang.MultiFn 0x7b60c3e "clojure.lang.MultiFn@7b60c3e"]
user=> (thing :hello)
Execution error (NullPointerException) at user/eval144 (REPL:1).
null
user=>

Someone was surprised by this behavior and missed the error that there was no dispatch function defined. Notable that there is some validation for defmulti:

 (defmulti thing [x] (fn [x] x))
Syntax error macroexpanding defmulti at (REPL:1:1).
The syntax for defmulti has changed. Example: (defmulti name dispatch-fn :default dispatch-value)
user=>

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

Sun, 26 Jul 2020 21:18:09 +0000

I'm implementing a small Lisp interpreter, which led me to discover this bug in the implementation of case:

(case "s"
  'quote "quote"
  "default")

;; Syntax error macroexpanding case at (org:localhost:56082(clj)*:131:16).
;; Duplicate case test constant: quote

I thought this might be a good workaround:

(case 'quote
  (symbol "quote") "quote"
  "default")
;; => "default"

This doesn't work, it returns "default".

Strangely, even though (symbol quote) would be invalid, since quote is not bound, THIS does "work" by returning "quote":

(case 'quote
  (symbol quote) "quote"
  "default")
;; => "quote"

Very weird. And look at this. Let's try a case of 'face. What will it return?

(case 'quote
  'face "face"
  "default")
;; => "face"

It matches 'quote!

Actually anything quoted matches:

(case 'quote
  (quote 123) "123"
  "default")
;; => "123"

Hopefully this will be enough for this to make sense to someone with knowledge of case's macroexpansion.

Cheers!

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

Tue, 23 Jun 2020 21:13:59 +0000

I was trying to use a library that calls requiring-resolve (which any attempt to call would throw an IllegalStateException). While trying to find the issue, I found that when I call

System.out.println(Clojure.var("clojure.core/deref").invoke(Clojure.var("clojure.core/*clojure-version*")));

I get

Unbound: #'clojure.core/*clojure-version*

Is there some way to fix this?

Improve error messages for clojure.core/case

Fri, 13 Mar 2020 04:44:30 +0000

The error message generated when case encounters a non-matching clause uses str, resulting in nil being rendered as an empty string, and strings without quote marks.

For example:

(let [x nil]
  (case x
    1 :a 2 :b))
;; =>
;; Unhandled java.lang.IllegalArgumentException
;; No matching clause for x:

And the potentially confusing

(let [x "1"]
  (case x
    1 :a 2 :b))
;; =>
;; Unhandled java.lang.IllegalArgumentException
;; No matching clause for x: 1

Would it be less ambiguous to use pr-str for the value resulting in nil and "1" respectively?

Note: a similar issue was raised for Clojurescript here:
https://ask.clojure.org/index.php/6575/improve-error-messages-using-instead-when-printing-objects

Logged: https://clojure.atlassian.net/browse/CLJ-2564

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?

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

Tue, 06 Aug 2019 14:09:25 +0000

Clojure stacktraces are pretty cryptic and hard to follow, is there a library to display better errors or format the stacktraces?

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

Fri, 02 Aug 2019 15:19:51 +0000

I'm using s/explain-data within if-let to decide in one pass whether some data is valid or whether I should throw an exception:

(if-let [explanation (s/explain-data spec x)]
(throw (ex-info "Invalid" explanation))
x)

When handled by my Cursive repl, this is rendered as

Execution error - invalid arguments to name.space/function-name at (source.clj:nn)
...then the explain-str form of the error

My problem is that the message is misleading—there could be reasons other than "invalid arguments" that the data were invalid! Wouldn't it be better if the text was simply:

Execution error - data validation failed within name.space/function-name at (source.clj:nn)

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

Fri, 26 Jul 2019 19:10:03 +0000

Using lein run. There are no references to my *.clj file anywhere, so I don't know where this java.lang.NullPointerException is coming from??

Exception in thread "main" Syntax error compiling at (/tmp/form-init542794133375754487.clj:1:72).
    at clojure.lang.Compiler.load(Compiler.java:7647)
    at clojure.lang.Compiler.loadFile(Compiler.java:7573)
    at clojure.main$load_script.invokeStatic(main.clj:452)
    at clojure.main$init_opt.invokeStatic(main.clj:454)
    at clojure.main$init_opt.invoke(main.clj:454)
    at clojure.main$initialize.invokeStatic(main.clj:485)
    at clojure.main$null_opt.invokeStatic(main.clj:519)
    at clojure.main$null_opt.invoke(main.clj:516)
    at clojure.main$main.invokeStatic(main.clj:598)
    at clojure.main$main.doInvoke(main.clj:561)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.lang.Var.applyTo(Var.java:705)
    at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
    at xinova.model$reload_dbs.invokeStatic(model.clj:78)
    at xinova.model$reload_dbs.invoke(model.clj:78)
    at xinova.core$_main.invokeStatic(core.clj:18)
    at xinova.core$_main.doInvoke(core.clj:14)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.lang.Var.invoke(Var.java:384)
    at user$eval140.invokeStatic(form-init542794133375754487.clj:1)
    at user$eval140.invoke(form-init542794133375754487.clj:1)
    at clojure.lang.Compiler.eval(Compiler.java:7176)
    at clojure.lang.Compiler.eval(Compiler.java:7166)
    at clojure.lang.Compiler.load(Compiler.java:7635)
    ... 12 more

Provide guidance on configuring error printer for handling errors

Wed, 03 Apr 2019 01:48:27 +0000

As of Clojure 1.10.1-beta1, errors in non-REPL environments are handled with `ex-str`, which is nice because `ex-str` in turn calls `*explain-out*` which is user-configurable.

However, there is not clear guidance on how best to configure `s/*explain-out*` such that this configuration will be run before other namespaces are loaded. Perhaps 'user.clj' is the correct place for this, but will that always be loaded for all non-REPL tasks?

For instance, this code would set up Expound, but right now I'm not sure how to reliably run it before other namespaces load:

(require '[expound.alpha :as expound] '[clojure.spec.alpha :as s])
(alter-var-root #'s/*explain-out* (constantly (expound/custom-printer {:print-specs? false :show-valid-values? true :theme :figwheel-theme})))

Use "constructor" instead of "ctor" in Compiler error messages

Mon, 26 Nov 2018 13:57:54 +0000

In this example:

user=> (java.net.URL. #_"missing arg") Syntax error (IllegalArgumentException) compiling new at (REPL:1:1). No matching ctor found for class java.net.URL

the use of "ctor" is confusing. It matches the code variable name, but the user isn't looking at that.

Patch: CLJ-2445.patch - replace "ctor" with "constructor" in error messages.

Prescreened by: Alex Miller

Separate compiler exceptions into :compilation and :compile-syntax-check

Tue, 13 Nov 2018 21:05:29 +0000

With the new error reporting phases in Clojure 1.10, we identified two separate phases - :compile-syntax-check (for syntax errors found by compiler) and :compilation for errors that occur during compilation but that are not syntax errors.

Example of the latter:

user=> a/b
Syntax error compiling at (REPL:0:0).
No such namespace: a
user=> (ex-data *e)
#:clojure.error{:phase :compile-syntax-check, :line 0, :column 0, :source "NO_SOURCE_PATH"}

The syntax here is fine, just a is not a known namespace.

The Compiler adheres to no patterns in differentiating between these two. We should go through and make this consistent, either through exception types or explicitly specifying the phase in a CompilerException.

Confusing function name suffixes in error messages

Sat, 03 Nov 2018 13:01:54 +0000

Some core function names are reported in error messages with an odd munging suffix.

For example, when passing the wrong number of arguments to {{inc}}, {{assoc}}, and {{dissoc}}, each error message reports the function name differently:

clj -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta4"}}}'

user=> (inc)
Syntax error compiling inc at (1:1).
Wrong number of args (0) passed to: clojure.core/inc--inliner--5436
user=> (assoc)
Evaluation error (ArityException) at clojure.lang.AFn.throwArity (AFn.java:429).
Wrong number of args (0) passed to: clojure.core/assoc--5316
user=> (dissoc)
Evaluation error (ArityException) at clojure.lang.AFn.throwArity (AFn.java:429).
Wrong number of args (0) passed to: clojure.core/dissoc

From the user's point of view, this behaviour is unmotivated and confusing. Perhaps such names should be further demunged and printed without the suffix.

Multimethods don't have the correct method name in stacktraces.

Mon, 22 Oct 2018 16:50:22 +0000

Describing the user-facing problem:

When an exception is thrown and there is a multimethod in the stacktrace, the name of the multimethod is not shown in the callstack.

When I execute this code:

(defmulti dispatcher (fn [item] (:type item)))

(defmethod dispatcher "cat"
  [{:keys [lives]}]
  (/ lives 0))

(dispatcher {:type "cat" :lives 9})
*e

I get the following stack trace:

[clojure.lang.Numbers divide "Numbers.java" 163]
[clojure.lang.Numbers divide "Numbers.java" 3813]
[config_compilation.core$eval20467$fn__20469 invoke "/Users/marc/dev/circleci/orb-registry/server/src/config_compilation/core.clj" 198]
[clojure.lang.MultiFn invoke "MultiFn.java" 229]
... snip ...

The function name is {{config_compilation.core$eval20467$fn__20469}}.

If I use {{defn}} to declare {{dispatcher}} directly, I get the following stacktrace:

(defn dispatcher
  [{:keys [lives]}]
  (/ lives 0))

(dispatcher {:type "cat" :lives 9})
*e

[clojure.lang.Numbers divide "Numbers.java" 163]
[clojure.lang.Numbers divide "Numbers.java" 3813]
[config_compilation.core$dispatcher invokeStatic "/Users/marc/dev/circleci/orb-registry/server/src/config_compilation/core.clj" 202]
[config_compilation.core$dispatcher invoke "/Users/marc/dev/circleci/orb-registry/server/src/config_compilation/core.clj" 200]
... snip ...

The function name is given correctly as {{config_compilation.core$dispatcher}}.

I'm guessing that the issue could be that the {{defmulti}} macro not setting the {{:name}} metadata, or perhaps not passing the {{:name}} metadata to the compiler correctly.

Unfriendly Java cast expection when compile-path is set incorrectly

Thu, 04 Oct 2018 09:55:23 +0000

When *compile-path* is not set to a String but to a java.io.File (that's what boot-clj does at the moment). You get a Cast exception in the compiler when trying to use it from the boot repl. Common wisdom seems to be to not compile from the repl, people say don't use gen-class. I find this unfortunate for when you do want to use gen-class and iterate quickly.

I haven't tested all older versions for this issue, but git blame shows that the code that should help here wasn't changed for 10 years:
https://github.com/clojure/clojure/blame/master/src/clj/clojure/core.clj#L6073
https://github.com/clojure/clojure/blame/master/src/jvm/clojure/lang/Compiler.java#L7643

My workaround now is:

(defn compile-safely [ns-name]
  (let [compile-path-class *compile-path*
        corrected-path (cond
                         (instance? java.io.File compile-path-class) (.getAbsolutePath *compile-path*)
                         (instance? String compile-path-class)       *compile-path*
                         :else
                         (throw (ex-info "Unsupported class" {:class (class compile-path-class)})))]
    (binding [*compile-path* corrected-path]
      (compile ns-name))))

I suggest to put the type check in the 'clojure.core/compile function.

Omit "null" Exception message from error output

Wed, 05 Sep 2018 13:29:40 +0000

Current:

user=> ((do nil)) Evaluation error at user/eval4 (NO_SOURCE_FILE:3). NullPointerException null

After patch:

user=> ((do nil)) Evaluation error at user/eval4 (NO_SOURCE_FILE:3). NullPointerException

Patch: 0001-CLJ-2420-ignore-null-Exception-message-v2.patch

Prescreened by: Alex Miller

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

Fri, 29 Jun 2018 22:41:03 +0000

Steps:

(require '[clojure.test :refer [is]]) (is (thrown-with-msg? Exception #"123" (throw (ex-info nil {}))))

Expected:

FAIL in () (form-init1933636226458515246.clj:1) expected: (thrown-with-msg? Exception #"123" (throw (ex-info nil {}))) actual: ...

Actual:

`
ERROR in () (Matcher.java:1283)
expected: (thrown-with-msg? Exception #"123" (throw (ex-info nil {})))
actual: java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength (Matcher.java:1283)

java.util.regex.Matcher.reset (Matcher.java:309)
java.util.regex.Matcher.<init> (Matcher.java:229)
java.util.regex.Pattern.matcher (Pattern.java:1093)
clojure.core$re_matcher.invokeStatic (core.clj:4796)
clojure.core$re_find.invokeStatic (core.clj:4838)
clojure.core$re_find.invoke (core.clj:4838)
user$eval43312.invokeStatic (form-init1933636226458515246.clj:1)
user$eval43312.invoke (form-init1933636226458515246.clj:1)
clojure.lang.Compiler.eval (Compiler.java:7062)
clojure.lang.Compiler.eval (Compiler.java:7025)
clojure.core$eval.invokeStatic (core.clj:3206)
clojure.core$eval.invoke (core.clj:3202)
clojure.main$repl$read_eval_print__8572$fn__8575.invoke (main.clj:243)
clojure.main$repl$read_eval_print__8572.invoke (main.clj:243)
clojure.main$repl$fn__8581.invoke (main.clj:261)
clojure.main$repl.invokeStatic (main.clj:261)
clojure.main$repl.doInvoke (main.clj:177)
clojure.lang.RestFn.invoke (RestFn.java:1523)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__40865.invoke (interruptible_eval.clj:87)
clojure.lang.AFn.applyToHelper (AFn.java:152)
clojure.lang.AFn.applyTo (AFn.java:144)
clojure.core$apply.invokeStatic (core.clj:657)
clojure.core$with_bindings_STAR_.invokeStatic (core.clj:1965)
clojure.core$with_bindings_STAR_.doInvoke (core.clj:1965)
clojure.lang.RestFn.invoke (RestFn.java:425)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic (interruptible_eval.clj:85)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:55)
clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__40910$fn__40913.invoke (interruptible_eval.clj:222)
clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__40905.invoke (interruptible_eval.clj:190)
clojure.lang.AFn.run (AFn.java:22)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)
java.lang.Thread.run (Thread.java:748)

ClojureScript:

ERROR in () (TypeError:NaN:NaN) expected: (thrown-with-msg? js/Error #"123" (throw (ex-info nil {}))) actual: #object[TypeError TypeError: re-find must match against a string.]

Improve error message when calling a keyword with the wrong number of arguments

Thu, 03 May 2018 13:46:34 +0000

When you call a {{Keyword}} with the wrong number of arguments, the error message does not report how many arguments were passed:

(:kw "one" "two" "three") => java.lang.IllegalArgumentException: Wrong number of args passed to keyword: :kw

compare to calling an {{IFn}}, which does show the number of arguments passed:

(name "one" "two" "three") => clojure.lang.ArityException: Wrong number of args (3) passed to: core/name

The latter error message is more clear and makes it easier to debug.

The attached patch re-uses the {{ArityException}} class used elsewhere to generate error messages in the latter form when calling a keyword with the wrong number of arguments.

Addresses CLJ-1067

Patch: keyword-arity-exception-03.patch

Screened by: Alex Miller

clojure.lang.ExceptionInfo should not pass null cause in its two-arg constructor

Sun, 11 Feb 2018 00:51:48 +0000

The two-arg constructor for clojure.lang.ExceptionInfo chains to the 3-arg version, passing null as the cause. The 3-arg constructor then calls super with the null cause, above which line is the comment "null cause is equivalent to not passing a cause".

This is not actually true, as passing null here means the cause has been initialised, regardless of value. As a consequence, you can not call .initCause on the ex-info exception later. In my case, the 'cause' is not known when thrown: the exception is caught upstack, the cause added, then rethrown.

In summary, this expression will always throw an exception: (-> (ex-info "ex" {}) (.initCause (Exception. "cause"))).

The simple solution would be to call the 2-arg super, and call .initCause if cause is non-null.

Cheers,

Matt.

Line numbers in stack trace are wrong when type hints satisfaction fails

Mon, 27 Nov 2017 05:02:14 +0000

When I run the following file

`
(defn f [^double x] x)

(defn g []
(println)
(f nil))

(g)
`

I get the following stack trace

`
Exception in thread "main" java.lang.NullPointerException, compiling:(/.../example.clj:7:1)

at clojure.lang.Compiler.load(Compiler.java:7526)
at clojure.lang.Compiler.loadFile(Compiler.java:7452)
at clojure.main$load_script.invokeStatic(main.clj:278)
at clojure.main$script_opt.invokeStatic(main.clj:338)
at clojure.main$script_opt.invoke(main.clj:333)
at clojure.main$main.invokeStatic(main.clj:424)
at clojure.main$main.doInvoke(main.clj:387)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.main.main(main.java:37)

Caused by: java.lang.NullPointerException

at clojure.lang.RT.doubleCast(RT.java:1348)
at user$g.invokeStatic(example.clj:4)
at user$g.invoke(example.clj:3)
at user$eval147.invokeStatic(example.clj:7)
at user$eval147.invoke(example.clj:7)
at clojure.lang.Compiler.eval(Compiler.java:7062)
at clojure.lang.Compiler.load(Compiler.java:7514)
... 9 more

The line {{at user$g.invokeStatic(example.clj:4)}} here is quite misleading, because the error happens at line 5.

When calling a multi method with the wrong number of arguments, the error message could be better.

Tue, 07 Nov 2017 15:10:17 +0000

09:43 $ clj
Clojure 1.8.0
(defmulti foo :bar)
(defmethod foo :qix [quux znoot] (println 'hi))
#'user/foo
user=> #object[clojure.lang.MultiFn 0x205d38da "clojure.lang.MultiFn@205d38da"]
user=> (foo {:bar :qix})
ArityException Wrong number of args (1) passed to: user/eval5/fn--6 clojure.lang.AFn.throwArity (AFn.java:429)
user=>

It is an implementation detail that multi methods are implemented via anonymous functions. I would expect the error message to at least contain the name of the function that failed, in this case it should have been something like

ArityException Wrong number of args (1) passed to: user/eval5/foo--6 clojure.lang.AFn.throwArity (AFn.java:429)

Several approaches can be taken here:

The first (and simplest) is to change the definition of {{defmethod}} so that the anonymous function gets a name.
This leads to an error message like:

user=> (defmulti foo :bar)
(defmethod foo :qix [quux znoot] (println 'hi))
(foo {:bar :qix})#'user/foo
user=> #object[clojure.lang.MultiFn 0x4e928fbf "clojure.lang.MultiFn@4e928fbf"]
user=>
ArityException Wrong number of args (1) passed to: user/eval5/foo--6 clojure.lang.AFn.throwArity (AFn.java:429)
user=>

In addition to this, one could modify Compiler.java to look for the calls to "addMethod"

String prefix = "eval";
if (RT.count(form) > 2) {
   Object third = RT.nth(form, 2);
   if (third != null &&
       "clojure.core/addMethod".equals(third.toString()))
      prefix = "multi_fn";
}
ObjExpr fexpr = (ObjExpr) analyze(C.EXPRESSION, RT.list(FN, PersistentVector.EMPTY, form), prefix + RT.nextID());

which would give us error messages like

ArityException Wrong number of args (1) passed to: user/multi-fn5/foo--6 clojure.lang.AFn.throwArity (AFn.java:441)

LispReader.java and EdnReader.java exception messages could be much more informative.

Wed, 31 May 2017 20:13:55 +0000

The messages in the exceptions thrown by the readers would be much more informative if they included readily available information. There are many instances of this, but to name a few specific instances (all from LispReader.java, though there in most cases there are corresponding problems in EdnReader.java):

If the RegexReader class hits an unexpected EOF, it reports "EOF while reading regex". It would be helpful if the message included the first few characters of the regex it was trying to read -- available in sb -- as a guide to the person trying to locate the problem.
The same logic applies to StringReader.
In NamespaceMapReader, the error thrown if the namespaced map is not in fact a map could include the namespace symbol.
Whenever an odd number of elements in a map is detected, the exception could at least report the number of elements that the bad map did include, something like: "Map literal cannot contain 7 forms. Map literals must contain an even number of forms." Even better would be the first few forms.
The "Metadata can only be applied to IMetas" exception in MetaReader is not nearly as helpful as it could be. At the very least it should report the class of the thing that is not an IMeta.
With an additional argument, readDelimitedList could report the kind of thing that it was reading in the event that it hit the EOF. Without the additional argument it still report that it hit an EOF while trying to read the first or 4th or 29 element of a collection.

Error message for non integer index into vector could be improved.

Wed, 31 May 2017 19:49:07 +0000

The exception generated in APersistentVector/invoke and also in APersistentVector/assoc when the index is not an integer would be better if it included the class of the object actually passed in and would be better still if it included the actual value.

Catch multiple exceptions in a single catch block

Sun, 12 Mar 2017 22:56:47 +0000

Java 7 and up support multi-catch exceptions (http://www.oracle.com/technetwork/articles/java/java7exceptions-486908.html). It would be handy if Clojure also supported them to prevent catching something like Exception and then writing manual logic to check the Exception type, or duplicating the logic over multiple catch blocks.

A possible syntax for this could be:

`
(try (fn-that-throws)

 (catch (UnknownHostException NoRouteToHostException) e
   (go-offline)))

Prior art for this is a * } macro: https://gist.github.com/Gonzih/5814945.

One nuance to handle is

{quote}
Edit: Note that in Java 7, you cannot both catch ExceptionA& ExceptionB in the same time, if ExceptionB is inherited(directly or indirectly) from ExceptionA. Compiler will complain: The exception ExceptionB is already caught by the alternative ExceptionA. - http://stackoverflow.com/a/3495968/826486
{quote}

I tried searching to see if this had been asked already, but got mountains of results. I didn't see anything in the first few pages though.

Provide meaning error message when eval of function fails.

Sun, 15 May 2016 12:04:06 +0000

When attempting to eval a function, in some cases this fails with "No matching ctor found". This error does not clearly indicate the root cause. Suggest something like "cannot eval function" or something similar. See http://dev.clojure.org/jira/browse/CLJ-1206 for history relating to this ticket.

Bad type hints on a defn cause the compiler to throw a NPE

Fri, 04 Dec 2015 19:16:32 +0000

After CLJ-1232 was committed to master, it is possible for the Clojure compiler to throw a NPE if a defn is type hinted with a invalid type. This surfaces in CLJS where the defn macro is re-used by the ClojureScript compiler, but I think it raises the question: "Should a bad type hint result in a compiler exception?"

The offending line can be found here on GitHub: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L247

Clojure Q&A - Recent questions in Errors

"Nested" vs "lateral" exception causes

`(even? (range))` hangs

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

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

`ClassCastException` when misplacing `nth` args

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

Null pointer error when using filter

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

Problem Statement

Discussion

Repro:

Interest in beginner-friendly variant of (pst)?

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

Error : ClassCastException

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

problem with intersection

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

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

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

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

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

command works on Linux but fails on Windows

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

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

Improve error messages from `reify` forms

Literal set with duplicate values reports error with wrong line number

Stacktraces with clojure functions contain irrelevant information

Background

Context

Scope

Problem

Illustration

Possible solutions?

Do nothing

Merge stack elements

Make Clojure stack elements resemble code

Something else

Support for suppressed exceptions

signal an error on mulimethod without a dispatch function?

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

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

Improve error messages for clojure.core/case

Namespace.java: addAlias exception could be more informative

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

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

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

Provide guidance on configuring error printer for handling errors

Use "constructor" instead of "ctor" in Compiler error messages

Separate compiler exceptions into :compilation and :compile-syntax-check

Confusing function name suffixes in error messages

Multimethods don't have the correct method name in stacktraces.

Unfriendly Java cast expection when *compile-path* is set incorrectly

Omit "null" Exception message from error output

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

Improve error message when calling a keyword with the wrong number of arguments

clojure.lang.ExceptionInfo should not pass null cause in its two-arg constructor

Line numbers in stack trace are wrong when type hints satisfaction fails

When calling a multi method with the wrong number of arguments, the error message could be better.

LispReader.java and EdnReader.java exception messages could be much more informative.

Error message for non integer index into vector could be improved.

Catch multiple exceptions in a single catch block

Provide meaning error message when eval of function fails.

Bad type hints on a defn cause the compiler to throw a NPE

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

Unfriendly Java cast expection when compile-path is set incorrectly