Clojurians Log v2
clojure 2026-05-28
A quick heads up to pseudo-announce I've been tinkering with a notebook UI for https://github.com/rcarmo/go-joker as well as cleaning up the internals a bit more and triple-checking benchmarks because one of them had a correctness bug that reflected into the IR runtime (the benchmark values are meaningless, but nice)
Are there any tricks for overriding or augmenting the default error handling (`clojure.main/report-error`) in clojure.main/main ? The context is: when I'm starting a Clojure application from source with clojure -M, if there is an exception that is not handled by the project code itself, I'd like to be able to capture that exception in my own tooling (to log it, to send it to my editor, etc.). But this is not possible because it gets handled by clojure.main/main. alter-var-root on clojure.main/report-error does not work because the whole clojure.main namespace is AOT-compiled.
Doesn't seem like it. I simply wrap the body of the -main function(s) with whatever I need.
Yes, that's what I'm doing now. But it is not ideal because I have to maintain those local changes indefinitely (I can't push them upstream because they are specific to my particular editor setup and would annoy my colleagues with entirely different setups).
And, I assume, catching stdout would not work in your case?
No, because this is a TUI application that writes heavily to stdout. (Another reason I would like to suppress the standard error reporting is that it breaks the TUI rendering.)
Probably worth posting the question at http://ask.clojure.org.
clojure.main/repl supports this with :caught fwiw
do the options at https://clojure.org/reference/repl_and_main#_as_launcher help at all? you could use none to print nothing or stderr to write to stderr (which you could redirect)
Oh, those might help--I didn't know about --report. I bet I could figure something out with process substitution....
Maybe we need a new option for :target that is a fully-qualified symbol that report-error calls requiring-resolve on and then invokes with the throwable?
That would be useful for my case, because it would let me deal with the actual exception object rather than its printed representation (like the existing targets).
For some additional context: I'm trying to do something along the lines of what is described here https://github.com/clojure-emacs/cider/issues/3850 to have uncaught exceptions show up in CIDER when I'm connected. But errors in the main thread for -M are never uncaught so there is no way to send them to CIDER.
I really hate it when things return Future or future instead of CompletableFuture , impossible to chain on those
Thanks but issue is when a library returns an ordinary future. These macros seem to be ergonomic wrappers for when you create your own completable future?
Yeah, I was mostly just agreeing that we had a bit of that frustration and wrote those macros to make using CFs "easier"...
future doesn't even implement everything in Future, let alone CompletableFuture...
Isn't the idea that you chain them by blocking?
I mean like (+ 1 @result) is chaining no?
no that is bad, you’re blocking the thread, and if you do this in another future, you’re making a thread there and blocking that. I guess virtual threads help here but those are kinda iffy
from my code I usually return CompletableFuture and you can use promesa to work with that or just call the java methods directly, or you can just use it as plain future
but with future you cannot really say “oh and when you’re done, run this post processing, async”
you have to either block on them or poll them
it’s bad either way
Right, but I wouldn't say it's bad, in that it's not good for when you want highly asynchronous non-blocking code, but for just running background jobs and waiting for the results it's decent. I'd say I haven't seen many things return future. That's probably a bit weird. It's much better for something to be sync and if you want to fire it off async you wrap it yourself.