@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.