This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-25
Channels
- # aws (2)
- # aws-lambda (2)
- # beginners (95)
- # boot (47)
- # cider (13)
- # clara (5)
- # cljs-dev (36)
- # cljsjs (9)
- # clojure (51)
- # clojure-austin (1)
- # clojure-greece (25)
- # clojure-italy (4)
- # clojure-japan (10)
- # clojure-russia (13)
- # clojure-spec (61)
- # clojure-uk (25)
- # clojurescript (26)
- # core-matrix (5)
- # cursive (8)
- # data-science (7)
- # datomic (43)
- # dirac (2)
- # emacs (8)
- # events (3)
- # fulcro (17)
- # graphql (29)
- # jobs-rus (4)
- # lambdaisland (4)
- # lein-figwheel (3)
- # leiningen (60)
- # luminus (15)
- # lumo (8)
- # mount (3)
- # off-topic (28)
- # om (22)
- # onyx (115)
- # other-languages (6)
- # pedestal (5)
- # re-frame (41)
- # reagent (12)
- # ring-swagger (12)
- # shadow-cljs (127)
- # unrepl (27)
- # yada (5)
@alexyakushev @seancorfield Works for boot-cljs/boot-alt-test and others. Are you running latest Boot?
@juhoteperi Running 2.7.2
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?
build.boot
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.lang.Thread.run Thread.java: 745
java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 617
java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1142
java.util.concurrent.FutureTask.run FutureTask.java: 266
...
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](https://github.com/Deraen/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 ?
@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 😕