Fork me on GitHub
#boot
<
2017-10-25
>
juhoteperi07:10:14

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

juhoteperi15:10:41

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

juhoteperi15:10:18

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

seancorfield15:10:47

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

juhoteperi15:10:47

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

juhoteperi15:10:14

Could you try moving it to separate file?

seancorfield15:10:40

And running it how, exactly?

juhoteperi15:10:58

then just requiring that file in build.boot

juhoteperi15:10:05

like with packaged tasks

seancorfield15:10:07

'k will try that...

juhoteperi15:10:27

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

juhoteperi15:10:54

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

juhoteperi15:10:02

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

juhoteperi15:10:20

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

seancorfield16:10:12

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

seancorfield16:10:14

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

juhoteperi16:10:17

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

seancorfield16:10:35

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.

seancorfield16:10:01

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.

seancorfield16:10:24

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

seancorfield16:10:19

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

seancorfield16:10:36

(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)

seancorfield16:10:49

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) 🙂

juhoteperi16:10:54

You can test [saapas](https://github.com/Deraen/saapas), modify a test to fail and run boot watch alt-test

seancorfield17:10:08

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

seancorfield17:10:53

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

juhoteperi17:10:27

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

seancorfield17:10:27

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

seancorfield17:10:54

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

seancorfield17:10:12

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.

qqq19:10:23

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 ?

qqq19:10:51

self answe: :cljs-asset-path

seancorfield19:10:17

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

juhoteperi19:10:58

First is fine, not sure about second

seancorfield19:10:35

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.

juhoteperi19:10:13

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

seancorfield19:10:43

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

juhoteperi20:10:43

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

seancorfield20:10:13

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 🙂

juhoteperi20:10:25

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

juhoteperi20:10:33

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

seancorfield20:10:30

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.

seancorfield20:10:54

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

juhoteperi20:10:18

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