Fork me on GitHub

@alexyakushev @seancorfield Works for boot-cljs/boot-alt-test and others. Are you running latest Boot?


Looking at the @alexyakushev stack trace, it could be the ex-info with correct data is wrapped in another ex-info


If you throw the exception inside pod, you probably need to catch and rethrow correct exception outside of the pod


@juhoteperi not throwing in a pod, just in task, for argument validation.


Hmm, again it is wrapped in another ex-info. Is this task in build.boot or separate file?


Could you try moving it to separate file?


And running it how, exactly?


then just requiring that file in build.boot


like with packaged tasks


'k will try that...


not sure why that would matter... but something is adding that ex-info with line information there


Boot should probably merge ex-data there so e.g. omit-stacktrace? property is present in the top-most exception


Not sure if having task in separate file helps, though I'm quite sure I have tested this with boot-cljs (without watch)


Inside watch task exception handling works a bit differently and I'm sure that works at least


Having the task in a separate file makes no difference. Running boot watch test-cfml still prints a stacktrace on exit.


That line you linked to is in a catch for CompilerException -- which this is not.


Works with watch alt-test but without watch it prints stacktrace


If you wrap the throw in (boot.util/exit-ok ...) it suppresses the stacktrace for the throw -- but still prints a stacktrace for the boot.App$exit 1 thrown in the main of Boot.


I looked at the logic in Boot and I couldn't see how it would print the exception without the stacktrace in normal execution, to be honest.


I know where the omit-stacktrace? logic is -- but I don't see how it could work.


Even if I move the throw inside the with-pass-thru and run it with watch, I still get a stacktrace:

(! 1248)-> boot -s src watch test-cfml-x

Starting file watcher (CTRL-C to quit)...

You must specify which tests to run: -u / --unit, -i / --integration.
java.util.concurrent.ThreadPoolExecutor$  617
 java.util.concurrent.ThreadPoolExecutor.runWorker 1142
               clojure.core/binding-conveyor-fn/fn                 core.clj: 2027
                                 boot.core/boot/fn                 core.clj: 1031
                               boot.core/run-tasks                 core.clj: 1021
                    boot.task.built-in/fn/fn/fn/fn             built_in.clj:  439
                 boot.task.built-in/fn/fn/fn/fn/fn             built_in.clj:  442
              boot.task.built-in/fn/fn/fn/fn/fn/fn             built_in.clj:  442
                       cfml-test/eval1080/fn/fn/fn            cfml_test.clj:   22
                    cfml-test/eval1080/fn/fn/fn/fn            cfml_test.clj:   22
                 cfml-test/eval1080/fn/fn/fn/fn/fn            cfml_test.clj:   22
boot.App$Exit: 1


(it prints the original exception without a stacktrace but then exits with a status of 1 via throwing boot.App$Exit and that stacktrace appears)


I've gotten used to Boot's ugly stacktrace-on-exit behavior so it doesn't bother me too much, but I'd sure like :boot.util/omit-stacktrace? to work in all cases (as expected) 🙂


You can test [saapas](, modify a test to fail and run boot watch alt-test


I don't doubt it works for you in some situations 🙂 But it is clearly not working for me (in any situation) nor for @alexyakushev


I'm puzzled at to where the line: 1524 or line: 1525 is coming from since my build.boot file is not that long.


Boot will prepend some code to build.boot before evaluating that


OK. Surprised it appends that much code. I'll try to find some time to debug this with a local build of Boot...


...not sure I've ever tried to build Boot locally so this will be an adventure 🙂


OK, if that catch of the CompilerException merged (ex-info c) into the sorted-map it would suppress the stacktrace -- although you then do not see the additional information in the output.


How do I configure boot-reload properly? 1. boot-reload is trying to load from "localhost/main.out/foo/bar.js" 2. the actual file is located at "localhost/dev/main.out/foo/bar.js" 3. note the extra "dev" in #2 question: how do I get boot-reload to load from /dev/main.out instead of /main.out ?


self answe: :cljs-asset-path


@juhoteperi I submitted two PRs: one merges ex-data into that boot.main exception so :boot.util/omit-stacktrace? is preserved; the other adds the display of user-supplied ex-data to the (red) failure message when omitting a stacktrace.


First is fine, not sure about second


That produces output like this if I add {:boot.util/omit-stacktrace? true :some "other" :stuff 42} to my ex-info:

(! 1291)-> bin/boot-core test-cfml
You must specify which tests to run: -u / --unit, -i / --integration.
{:line 1525, :some "other", :stuff 42}
Yeah, I wasn't sure how you'd feel about that one, which is why they're separate.


This affects just cases with omit-stacktrace, I think in this case it best the task author makes sure the message contains all the necessary information


It probably ought to go through the full pretty printing machinery rather than plain pprint so that it handles depth and alignment and so on -- but I didn't want to tackle that right now 🙂 Yeah, requiring the task author to make that trade off is reasonable. I think we only throw with additional information in a few places (but test failure summaries would be one of them).


Test runner will print the summary so ex-data is probably unncessary


We have a task that runs multiple subprojects worth of tests and aggregates the results and puts that in the ex-info, but I can clean that up. We also have a few tasks that throw fairly arbitrary data (and rely on the pretty-printing in Boot/Aviso to display nicely), so I'll just live with the stacktraces there 🙂


Boot.worker contains puget which allows pretty printing (with colors)


Heh, looks like puget is no longer used by Boot, it was added at some point but then the use was reverted


If I have more time later, I may work through a fully pretty-printed version of the ex-data stuff and submit a PR that adds :boot.util/print-ex-data? as a modifier for :boot.util/omit-stacktrace? to handle this. Maybe.


(basically I'd lift the Aviso pretty-printing of properties for that)


Puget might be better fit for printting maps than aviso, but that is not bundled with Boot 😕