Clojure Q&A - Recent questions tagged error-messages

require yields confusing "namespace ... not found after loading ..." error if masked by empty test file

Sat, 11 Jul 2026 02:54:34 +0000

My home.clj was requring chess.llm, neither file had compilation issues, so I found this error below very strange and I couldn't figure it out.

user=> (require 'chess.routes.home :reload)                                                                    
2026-07-10 22:09:37,296 [nREPL-session-cedf8a12-a034-475d-a72c-7683c52bca15]
Syntax error compiling at (chess/routes/home.clj:1:1).
namespace 'chess.llm' not found after loading '/chess/llm'

I even tried asking AI for help with troubleshooting but it went down the wrong paths looking for circular dependencies. It wasn't until I copied llm.clj to a different file named caca.clj while only updating the ns declaration "chess.llm => chess.caca" and corresponding requires in my home.clj, that everything loaded correctly.

It turns out that I had an empty test file test/chess/llm.clj that was somehow messing up the compilation, and removing this empty test file file, or adding a proper ns declaration, solved the issue.

I'm reporting this because it would help the next Clojure developer if the error message were more indicative of the bad test file, perhaps by including the full file path.

Here's the AI-generated explanation of this report:

Title

require yields confusing "namespace not found after loading" error if masked by empty file earlier in classpath

Environment

Clojure Version: 1.11+ / 1.12
Build Tool: Leiningen / Clojure CLI

Description

When attempting to require a valid Clojure namespace, if a completely empty .clj file with the exact same relative file path exists earlier in the classpath sequence (for example, in test/ when test/ precedes src/ in the active profile), Clojure throws a misleading error.

The compiler successfully locates and loads the empty file, but because the file lacks an (ns ...) declaration, it fails to find the registered namespace in memory. This effectively masks the actual, working source file further down the classpath, resulting in an error message that mistakenly implies the namespace naming is incorrect, rather than indicating a classpath prioritization issue.

Steps to Reproduce

Create a project layout where test/ takes priority over src/ on the classpath.
Create a valid file at src/chess/llm.clj containing:
`clojure
(ns chess.llm)
(defn call-llm [] :ok)
`
Create an empty file at test/chess/llm.clj (size 0 bytes, absolutely no content).
Launch a REPL and evaluate: (require 'chess.llm)

Expected Behavior

The compiler should either:
1. Skip empty files on the classpath and continue searching subsequent paths for a matching file containing a valid ns form.
2. Throw a more descriptive lifecycle error indicating which exact file path was targeted (e.g., namespace 'chess.llm' not found after loading empty file: test/chess/llm.clj).

Actual Behavior

The execution fails completely with a vague stack trace:
`clojure
Caused by: java.lang.Exception: namespace 'chess.llm' not found after loading '/chess/llm'
`

Changing type tags can lead to cryptic errors

Fri, 05 Jun 2026 08:03:00 +0000

Reporting this as an example of a particularly cryptic error message. Admittedly not the most common thing, but when doing REPL-driven dev with code that uses primitive type tags it can happen.

The issue here as I understand it is that IFn contains a few hundred interfaces with some permutation of primitive input and output types, with names like LLO and ODOL. Functions that call this are compiled to call the primitive interface to avoid boxing,rather than the generic IFn. If the function is then redefined without or with different primitive tags, then the compiled calling code is no longer calling the right interface.

(defn foo ^long [^long x]
  x)

(defn bar []
  (+ (foo 3) (foo 4)))

(bar)

(defn foo [x] x)

(bar) ;;=> throws: class my.ns$foo cannot be cast to class  clojure.lang.IFn$LL

`doseq` and `for` expands body twice

Wed, 26 Feb 2025 23:15:06 +0000

The bodies of doseq and for seem to be duplicated in their expansions.

$ clojure
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
:expand
nil
user=> (for [_ nil] (a))
:expand
:expand
()

I found the same problem in ClojureScript. I could not find an existing discussion about this so I'm not sure if this is by design, apologies if so. I'm aware that these macros have a large code footprint and that doseq cannot use closures (the usual way to prevent exponential expansion), but I missed this detail.

This leads to exponential code blowup if these forms are nested. Artificial demonstration:

$ clojure
Clojure 1.12.0
user=> (def counter (atom -1))
#'user/counter
user=> (defmacro a [] (prn :expand (swap! counter inc)))
#'user/a
user=> #(doseq [_ 1] (doseq [_ 2] (doseq [_ 3] (doseq [_ 4] (a)))))
:expand 0
:expand 1
:expand 2
:expand 3
:expand 4
:expand 5
:expand 6
:expand 7
:expand 8
:expand 9
:expand 10
:expand 11
:expand 12
:expand 13
:expand 14
:expand 15
#object[user$eval926$fn__927 0x76563d26 "user$eval926$fn__927@76563d26"]

This might be especially relevant to core.async, where placing go under doseq is idiomatic, since go is expensive in both expansion time and code size.

user=> (time (eval '(doseq [_ nil] (a/go (doseq [_ nil] (a/go (doseq [_ nil] (a/go))))))))
"Elapsed time: 837.230917 msecs"
nil

It also leads to duplicated reflection warnings from the fully expanded forms, which is how I found this problem.

user=> (doseq [_ nil] (Thread/sleep (identity 1)))
Reflection warning, NO_SOURCE_PATH:1:16 - call to static method sleep on java.lang.Thread can't be resolved (argument types: unknown).
Reflection warning, NO_SOURCE_PATH:1:16 - call to static method sleep on java.lang.Thread can't be resolved (argument types: unknown).
nil

I believe the exponential expansion for doseq was introduced in Clojure 1.1.0 with support for chunked seqs with this commit.

$ clojure -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.0.0"}}}' 
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.pom from central
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.jar from central
Clojure 1.0.0-
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
nil
user=> ^D
$ clojure -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.1.0"}}}'
Downloading: org/clojure/clojure/1.1.0/clojure-1.1.0.pom from central
Downloading: org/clojure/clojure/1.1.0/clojure-1.1.0.jar from central
Clojure 1.1.0
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
:expand
nil
user=>

At first I wasn't sure if this was hopeless, but I think doseq is fixable fusing the chunked and non-chunked cases like so:

(defmacro doseq
  "Repeatedly executes body (presumably for side-effects) with
  bindings and filtering as provided by \"for\".  Does not retain
  the head of the sequence. Returns nil.
  
  Unlike clojure.core/doseq, does not cause exponential macro expansion
  of expressions in bindings or body."
  [seq-exprs & body]
  (#'clojure.core/assert-args
     (vector? seq-exprs) "a vector for its binding"
     (even? (count seq-exprs)) "an even number of forms in binding vector")
  (let [step (fn step [recform exprs]
               (if-not exprs
                 [true `(do ~@body)]
                 (let [k (first exprs)
                       v (second exprs)]
                   (if (keyword? k)
                     (let [steppair (step recform (nnext exprs))
                           needrec (steppair 0)
                           subform (steppair 1)]
                       (cond
                         (= k :let) [needrec `(let ~v ~subform)]
                         (= k :while) [false `(when ~v
                                                ~subform
                                                ~@(when needrec [recform]))]
                         (= k :when) [false `(if ~v
                                               (do
                                                 ~subform
                                                 ~@(when needrec [recform]))
                                               ~recform)]))
                     (let [seq- (gensym "seq_")
                           chunk- (with-meta (gensym "chunk_")
                                             {:tag 'clojure.lang.IChunk})
                           count- (gensym "count_")
                           i- (gensym "i_")
                           in-chunk- (gensym "in-chunk_")
                           recform `(if ~in-chunk-
                                      (recur ~seq- ~chunk- ~count- (unchecked-inc ~i-))
                                      (recur (next ~seq-) nil 0 0))
                           steppair (step recform (nnext exprs))
                           needrec (steppair 0)
                           subform (steppair 1)]
                       [true
                        `(loop [~seq- (seq ~v), ~chunk- nil,
                                ~count- 0, ~i- 0]
                           (let [~in-chunk- (< ~i- ~count-)
                                 ~seq- (if ~in-chunk- ~seq- (seq ~seq-))]
                             (when (if ~in-chunk- true ~seq-)
                               (let [chunked?# (if ~in-chunk- false (chunked-seq? ~seq-))
                                     ~k (if ~in-chunk-
                                          (.nth ~chunk- ~i-)
                                          (if chunked?# nil (first ~seq-)))]
                                 (if (if ~in-chunk- false chunked?#)
                                   (let [c# (chunk-first ~seq-)]
                                     (recur (chunk-rest ~seq-) c#
                                            (int (count c#)) (int 0)))
                                   (do ~subform
                                       ~@(when needrec [recform])))))))])))))]
    (nth (step nil (seq seq-exprs)) 1)))

No path in loop recur arg warning

Sat, 21 Sep 2024 13:12:31 +0000

Reflection warnings, such as for reflective method calls, are printed with the full source path (Compiler/SOURCE_PATH). This is different in case of the warning about loop recur args, printed with the source filename only (Compiler/SOURCE):

(set! *warn-on-reflection* true)

(defn reflective-method-call [] (.substring (try "") 0))

(defn boxed-recur-arg [] (loop [i 0] (recur (try i))))

...which prints:

Reflection warning, /home/pawel/dev/project/src/core.clj:22:33 - call to method substring can't be resolved (target class is unknown).
core.clj:24 recur arg for primitive local: i is not matching primitive, had: Object, needed: long
Auto-boxing loop arg: i

IMHO, the path is useful, especially if the filename is generic and inside a dependency.

Method Values and Syntax Errors

Tue, 13 Feb 2024 14:16:48 +0000

Copied from this reddit comment:

So if an ambiguous method is a syntax error (syntax, really?), does that mean that when I update a Java lib that provides a new overload, it will break my code? Even worse, if I have a Clojure lib on the classpath that uses a Java lib, and then update the Java lib and it now provides another overload, the Clojure lib breaks. This would be bad and could result in all kinds of update hell.

Adding an overload is a very common backwards compatible change in Java code that should be expected. Please don't make it create "syntax" errors in Clojure wrappers.

My own words:

One of Clojure's strengths is the resiliency of code, that something written years ago still works today. This has historically applied to libraries that provide idiomatic wrappers around Java libraries as well. However, the use of syntax errors instead of falling back to reflection means that such libraries (if they use the new method values syntax) will be more brittle than other interop code, limiting its usefulness in long-lived code.

I understand the reasons for using hard errors (performance, clarity, simplicity), but I agree that it's a strange choice given Clojure's otherwise incredible flexibility and willingness to support a variety of usages.

What is lost or degraded by falling back to reflection (and a reflection warning) in ambiguous cases?

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?

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?

exceptions from a macro compilation do not contain at all "my source code"

Mon, 03 Jul 2023 18:38:52 +0000

When a exception is thrown at macro compilation time,
the stack trace does not contain the "originating line", at least in my case.

So when I want to look "where" in my code the issue starts, the stack trace does not help.

Specially for a Clojure beginner (from a Java background), it might not be obvious that macro compilation is existing and was the reason that a stack trace does not contain "my starting line".

Quite some libraries use "macros" for "normal operations".

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.

improve syntax errors on tagged-literals

Wed, 28 Sep 2022 13:24:40 +0000

When we write a symbol in the UUID literal, the reported error message is wrong

(as of 1.11.1)

clojure -M -e '#uuid id'
Execution error (AssertionError) at clojure.main/main (main.java:40).
Assert failed: (string? form)

It is wrong because

It is not an execution error. Should be read or syntax error.
It does not include any ex-data: https://clojure.org/reference/repl_and_main#_error_printing

It should be something like this

Reader error (AssertionError) at clojure.uuid/default-uuid-reader (uuid.clj:12).
Assert failed: (string? form)

A second step improvement could be add spec support to data-literals, as macros do.

Syntax error reading #uuid id at (REPL:1)
id - failed: string? at: [:form]

From #clojure-dev slack channel

Alex: You don’t need anything special there - just an instrumented spec on the data reader fn

After run

(s/fdef clojure.uuid/default-uuid-reader :args (s/cat :form string?))
(clojure.spec.test.alpha/instrument `clojure.uuid/default-uuid-reader)

The message turns into

Syntax error reading source at (REPL:2:1).
Call to #'clojure.uuid/default-uuid-reader did not conform to spec.

This is a way better message.

Also, it includes a #:clojure.error{:phase :read-source} in ex-data.
So the fix could be just add a spec to clojure.uuid/default-uuid-reader

Can: "Alias already exists in namespace" be fixed?

Mon, 26 Sep 2022 13:51:27 +0000

When defining a namespace alias in an ns form, and then later changing the namespace that alias refers to, you get an error:

(ns foo.bar
  (:require [my.xxx :as xxx]))

I evaluate this in my REPL. Later I change it to:

(ns foo.bar
  (:require [other.xxx :as xxx]))

And I get this exception

java.lang.IllegalStateException
Alias xxx already exists in namespace foo.bar, aliasing my.xxx

That's a pretty gnarly sharp edge. Many people won't find a better solution than restarting their REPLs. Experienced Clojure developers will tell you to do

(ns-unalias *ns* 'xxx)

and re-evaluate the ns form, but that's a pretty silly workaround. The right thing to do would be to drop the old alias and pick up the new one.

You'd (I supposed) still have to re-evaluate the code that uses the alias before it gets picked up, but that's fairly consistent with Clojure's mental model IMO.

We can redefine vars, why can't we redefine namespace aliases?

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

Can the error message be cleaned up for <, >, etc. ?

Tue, 19 Apr 2022 23:10:14 +0000

(< nil 3) produces the error Cannot invoke "Object.getClass()" because "x" is null. Is there any room for improvement here?

My gut tells me that this hasn't been done due to performance reasons, but another user made the observation in Slack that it's in the static public Boolean lt(Object x, Object y) { branch of Numbers.java, so it might not be terrible to add the null checks to improve the error message.

Thanks,
Devin

clojure.test deftest exception reporting lists many useless stack frames

Wed, 30 Jun 2021 07:10:59 +0000

If an exception occurs during a clojure.test deftest, the error goes to clojure.test/report with :error key which will (by default) print the entire stack trace. The stack includes the test framework itself and (if invoked via an external test runner like lein test, clojure.main etc), yielding a stack depth of ~60 stack frames which is all incidental noise that is irrelevant.

There is a dyn var clojure.test/stack-trace-depth that defaults to nil (all). This dynvar can be bound around calls to the clojure.test runner to see less stack trace when an exception occurs during a test, but this is both difficult to set for external test runners and error prone.

It would be most useful to filter the framework noise from the bottom of the stack and present only the relevant frames.

Given a test like:

(ns foo.core-test
  (:require [clojure.test :refer :all]))

(deftest a-test
  (testing "FIXME, I fail."
    (throw (ex-info "I suck" {:a 1}))
    (is (= 0 1))))

the reported error (here from lein test, but any external runner is similar), only the top 2 lines are relevant, the rest is incidental noise:

ERROR in (a-test) (core_test.clj:13)
Uncaught exception, not in assertion.
expected: nil
  actual: clojure.lang.ExceptionInfo: I suck
{:a 1}
 at foo.core_test$fn__364.invokeStatic (core_test.clj:13)
    foo.core_test/fn (core_test.clj:11)
    clojure.test$test_var$fn__9737.invoke (test.clj:717)        ;; noise from here down
    clojure.test$test_var.invokeStatic (test.clj:717)
    clojure.test$test_var.invoke (test.clj:708)
    clojure.test$test_vars$fn__9763$fn__9768.invoke (test.clj:735)
    clojure.test$default_fixture.invokeStatic (test.clj:687)
    clojure.test$default_fixture.invoke (test.clj:683)
    clojure.test$test_vars$fn__9763.invoke (test.clj:735)
    clojure.test$default_fixture.invokeStatic (test.clj:687)
    clojure.test$default_fixture.invoke (test.clj:683)
    clojure.test$test_vars.invokeStatic (test.clj:731)
    clojure.test$test_all_vars.invokeStatic (test.clj:737)
    clojure.test$test_ns.invokeStatic (test.clj:758)
    clojure.test$test_ns.invoke (test.clj:743)
    user$eval224$fn__287.invoke (form-init4292042596091073068.clj:1)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.injected$compose_hooks$fn__154.doInvoke (form-init4292042596091073068.clj:1)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:665)
    clojure.core$apply.invoke (core.clj:660)
    leiningen.core.injected$run_hooks.invokeStatic (form-init4292042596091073068.clj:1)
    leiningen.core.injected$run_hooks.invoke (form-init4292042596091073068.clj:1)
    leiningen.core.injected$prepare_for_hooks$fn__159$fn__160.doInvoke (form-init4292042596091073068.clj:1)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$map$fn__5866.invoke (core.clj:2755)
    clojure.lang.LazySeq.sval (LazySeq.java:42)
    clojure.lang.LazySeq.seq (LazySeq.java:51)
    clojure.lang.Cons.next (Cons.java:39)
    clojure.lang.RT.boundedLength (RT.java:1792)
    clojure.lang.RestFn.applyTo (RestFn.java:130)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.test$run_tests.invokeStatic (test.clj:768)
    clojure.test$run_tests.doInvoke (test.clj:768)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:665)
    clojure.core$apply.invoke (core.clj:660)
    user$eval224$fn__299$fn__332.invoke (form-init4292042596091073068.clj:1)
    user$eval224$fn__299$fn__300.invoke (form-init4292042596091073068.clj:1)
    user$eval224$fn__299.invoke (form-init4292042596091073068.clj:1)
    user$eval224.invokeStatic (form-init4292042596091073068.clj:1)
    user$eval224.invoke (form-init4292042596091073068.clj:1)
    clojure.lang.Compiler.eval (Compiler.java:7177)
    clojure.lang.Compiler.eval (Compiler.java:7167)
    clojure.lang.Compiler.load (Compiler.java:7636)
    clojure.lang.Compiler.loadFile (Compiler.java:7574)
    clojure.main$load_script.invokeStatic (main.clj:475)
    clojure.main$init_opt.invokeStatic (main.clj:477)
    clojure.main$init_opt.invoke (main.clj:477)
    clojure.main$initialize.invokeStatic (main.clj:508)
    clojure.main$null_opt.invokeStatic (main.clj:542)
    clojure.main$null_opt.invoke (main.clj:539)
    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)

We are doing things elsewhere to filter frames and I don't think it would be that hard to filter this to improve the default experience (could still be a dyn var to not filter if needed).

Clojure CLI: --report incompatible with -X ?

Tue, 15 Jun 2021 19:29:34 +0000

Background:

My build runs in a container where I have no access to temporary files (they get thrown away as soon as the build completes, whether successfully or not). As a result I add --report stderr option to all invocations of the clojure command.
My build constructs an uberjar, using Depstar, which requires the use of the -X:... option.
I also use the -Srepro option.

Problem:

When a clojure command line includes the -X option, it doesn't appear that there's any way to also include --report stderr option. Here's some sample output:

$ clojure --report stderr -Srepro -X:uberjar
WARNING: Use of -A with clojure.main is deprecated, use -M instead
{:clojure.main/message
 "Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).\n-Srepro (No such file or directory)\n",
 :clojure.main/triage
 {:clojure.error/class java.io.FileNotFoundException,
  :clojure.error/line -2,
  :clojure.error/cause "-Srepro (No such file or directory)",
  :clojure.error/symbol java.io.FileInputStream/open0,
  :clojure.error/source "FileInputStream.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type java.io.FileNotFoundException,
    :message "-Srepro (No such file or directory)",
    :at [java.io.FileInputStream open0 "FileInputStream.java" -2]}],
  :trace
  [[java.io.FileInputStream open0 "FileInputStream.java" -2]
   [java.io.FileInputStream open "FileInputStream.java" 219]
   [java.io.FileInputStream <init> "FileInputStream.java" 157]
   [java.io.FileInputStream <init> "FileInputStream.java" 112]
   [clojure.lang.Compiler loadFile "Compiler.java" 7575]
   [clojure.main$load_script invokeStatic "main.clj" 475]
   [clojure.main$script_opt invokeStatic "main.clj" 535]
   [clojure.main$script_opt invoke "main.clj" 530]
   [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 "-Srepro (No such file or directory)"}}

Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).
-Srepro (No such file or directory)

With the first two options swapped:

$ clojure -Srepro --report stderr -X:uberjar
WARNING: Use of -A with clojure.main is deprecated, use -M instead
{:clojure.main/message
 "Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).\n-X:uberjar (No such file or directory)\n",
 :clojure.main/triage
 {:clojure.error/class java.io.FileNotFoundException,
  :clojure.error/line -2,
  :clojure.error/cause "-X:uberjar (No such file or directory)",
  :clojure.error/symbol java.io.FileInputStream/open0,
  :clojure.error/source "FileInputStream.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type java.io.FileNotFoundException,
    :message "-X:uberjar (No such file or directory)",
    :at [java.io.FileInputStream open0 "FileInputStream.java" -2]}],
  :trace
  [[java.io.FileInputStream open0 "FileInputStream.java" -2]
   [java.io.FileInputStream open "FileInputStream.java" 219]
   [java.io.FileInputStream <init> "FileInputStream.java" 157]
   [java.io.FileInputStream <init> "FileInputStream.java" 112]
   [clojure.lang.Compiler loadFile "Compiler.java" 7575]
   [clojure.main$load_script invokeStatic "main.clj" 475]
   [clojure.main$script_opt invokeStatic "main.clj" 535]
   [clojure.main$script_opt invoke "main.clj" 530]
   [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 "-X:uberjar (No such file or directory)"}}

Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).
-X:uberjar (No such file or directory)

Finally, the version of the CLI tools I'm using:

$ clojure --version
Clojure CLI version 1.10.3.855

So the question is: how can I ensure any uncaught exceptions thrown out of a -X function (in this case Depstar, but it could be anything) are written to stdout or stderr, rather than a temporary file that I can't access? Does -X bypass that (irritating) default behaviour of writing exception details to a temporary file, perhaps?

Missing error on silly destructuring mistake

Wed, 09 Sep 2020 07:32:08 +0000

I happened to define a function like this

(defn foo [{:keys [bar :as lol]}] lol)

Obviously the destructuring is wrong, it should have been

(defn foo [{:keys [bar] :as lol}] lol)

My question is then, should this destructuring error be caught by the specs for destructuring?

Unmatched paren in Reitit example

Fri, 22 Nov 2019 01:46:08 +0000

Hey! I'm getting an unmatched paren error on this function I got from reitit's example http-swagger project.

(def app
  (http/ring-handler
   (http/router
     [["/swagger.json"
        {:get {:no-doc true
         :swagger {:info {:title "my-api"
                          :description "with reitit-http"}}
         :handler (swagger/create-swagger-handler)}}]

 ["/files"
  {:swagger {:tags ["files"]}}

  ["/upload"
   {:post {:summary "upload a file"
           :parameters {:multipart {:file multipart/temp-file-part}}
           :responses {200 {:body {:name string?, :size int?}}}
           :handler (fn [{{{:keys [file]} :multipart} :parameters}]
                      {:status 200
                       :body {:name (:filename file)
                              :size (:size file)}})}}]

 ["/async"
  {:get {:swagger {:tags ["async"]}
         :summary "fetches random users asynchronously over the internet"
         :parameters {:query (s/keys :req-un [::results] :opt-un [::seed])}
         :responses {200 {:body any?}}
         :handler (fn [{{{:keys [seed results]} :query} :parameters}]
                    (d/chain
                     (aleph/get
                      "https://randomuser.me/api/"
                      {:query-params {:seed seed, :results results}})
                     :body
                     (partial m/decode "application/json")
                     :results
                     (fn [results]
                       {:status 200
                        :body results})))}}]

 ["/math"
  {:swagger {:tags ["math"]}}

  ["/plus"
   {:get {:summary "plus with data-spec query parameters"
          :parameters {:query {:x int?, :y int?}}
          :responses {200 {:body {:total pos-int?}}}
          :handler (fn [{{{:keys [x y]} :query} :parameters}]
                     {:status 200
                      :body {:total (+ x y)}})}
    :post {:summary "plus with data-spec body parameters"
           :parameters {:body {:x int?, :y int?}}
           :responses {200 {:body {:total int?}}}
           :handler (fn [{{{:keys [x y]} :body} :parameters}]
                      {:status 200
                       :body {:total (+ x y)}})}}]

  ["/minus"
   {:get {:summary "minus with clojure.spec query parameters"
          :parameters {:query (s/keys :req-un [::x ::y])}
          :responses {200 {:body (s/keys :req-un [::total])}}
          :handler (fn [{{{:keys [x y]} :query} :parameters}]
                     {:status 200
                      :body {:total (- x y)}})}
    :post {:summary "minus with clojure.spec body parameters"
           :parameters {:body (s/keys :req-un [::x ::y])}
           :responses {200 {:body (s/keys :req-un [::total])}}
           :handler (fn [{{{:keys [x y]} :body} :parameters}]
                      {:status 200
                       :body {:total (- x y)}})}}]]]

{:reitit.interceptor/transform dev/print-context-diffs ;; pretty context diffs
 :validate spec/validate ;; enable spec validation for route data
 :reitit.spec/wrap spell/closed ;; strict top-level validation
 :exception pretty/exception
 :data {:coercion reitit.coercion.spec/coercion
        :muuntaja m/instance
        :interceptors [;; swagger feature
                       swagger/swagger-feature
                       ;; query-params & form-params
                       (parameters/parameters-interceptor)
                       ;; content-negotiation
                       (muuntaja/format-negotiate-interceptor)
                       ;; encoding response body
                       (muuntaja/format-response-interceptor)
                       ;; exception handling
                       (exception/exception-interceptor)
                       ;; decoding request body
                       (muuntaja/format-request-interceptor)
                       ;; coercing response bodys
                       (coercion/coerce-response-interceptor)
                       ;; coercing request parameters
                       (coercion/coerce-request-interceptor)
                       ;; multipart
                       (multipart/multipart-interceptor)]}})
 (ring/routes
(swagger-ui/create-swagger-ui-handler
 {:path "/"
  :config {:validatorUrl nil
           :operationsSorter "alpha"}})
(ring/create-default-handler))
 {:executor sieppari/executor}))

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?