This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-15
Channels
- # babashka (41)
- # beginners (47)
- # calva (7)
- # cider (5)
- # cljsrn (2)
- # clojure (38)
- # clojure-europe (74)
- # clojure-nl (2)
- # clojure-spec (1)
- # clojure-uk (38)
- # clojurescript (42)
- # component (30)
- # core-async (2)
- # cryogen (6)
- # cursive (47)
- # datahike (7)
- # datomic (18)
- # defnpodcast (1)
- # fulcro (17)
- # graalvm (8)
- # graphql (4)
- # helix (5)
- # honeysql (5)
- # introduce-yourself (1)
- # jobs (5)
- # jobs-discuss (4)
- # malli (20)
- # meander (4)
- # mental-health (1)
- # off-topic (41)
- # pathom (18)
- # podcasts-discuss (2)
- # re-frame (20)
- # react (1)
- # reagent (22)
- # reitit (2)
- # releases (2)
- # remote-jobs (1)
- # reveal (2)
- # sci (10)
- # shadow-cljs (42)
- # sql (20)
- # tools-deps (7)
- # vim (2)
- # xtdb (51)
@alexmiller Peter (Monks) raises an interesting point on ask about -X
, given that — currently, at least — the exec stuff goes through this path:
exec "$JAVA_CMD" "${jvm_cache_opts[@]}" "${jvm_opts[@]}" "-Dclojure.basis=$basis_file" -classpath "$cp:$install_dir/libexec/exec.jar" clojure.main -m clojure.run.exec "${exec_args[@]}" "$@"
I wonder whether it’s worth adding detection of --report
as a CLI option and passing it into this line between clojure.main
and -m
?it needs more thought. exec does some handling now and it will not necessarily always go through clojure.main
similarly, some of the choices in exec I like better than what's in main. the exec stuff may eventually make its way into clojure core itself too.
I have little interest in adding either more options to -X or more special cases :)
That’s fair. Just thought I’d ask. Personally, with the improvements to error reporting in 1.10, I hardly ever need to rummage around in the temp EDN file, and I’ve never needed to do that in our CI system (BitBucket Pipelines).
-X follows the lead of other Clojure CLI stuff and will print in the case of an ex-info and throw (resulting in printed stack) in other cases. All error messages in exec and tools.deps throw ex-info so this mostly only yields a stack in unexpected cases. so far, that has been mostly a good strategy.
Yeah, I’ve started to switch over to pretty much only throwing ex-info
from my own code these days, figuring that having something upstream be able to print the ex-data
along with the message will be more valuable than some “random” Java exception.