Fork me on GitHub
#shadow-cljs
<
2020-01-03
>
tianshu10:01:11

Found something interest, with target :browser.

(defn foo [i]
  (throw (ex-info "hello" {:a 1})))
I can't get a meaningful stacktrace for this code, but I can get one for this
(defn foo [i]
  (throw (js/Error. "hello")))

thheller10:01:42

and what is the problem?

tianshu10:01:34

the problem is I don't know where the error comes if that is an ex-info.

thheller10:01:20

and do you have an example of that?

thheller10:01:40

as far as I know ex-info only adds 2 or 3 elements to the stacktrace

thheller10:01:48

but preserves the original

tianshu10:01:48

yes, wait a moment.

tianshu10:01:17

This is the error for js/Error

main.js:2218 failed to load fullstack_explore.app.js Error
    at Object.fullstack_explore$app$foo [as foo] (app.cljs:6)
    at eval (app.cljs:8)
    at eval (<anonymous>)
    at Object.goog.globalEval (main.js:836)
    at Object.env.evalLoad (main.js:2216)
    at main.js:2396
And this is the error for ex-info
failed to load fullstack_explore.app.js #error {:message "", :data {}}
env.evalLoad @ main.js:2218
(anonymous) @ main.js:2396

thheller10:01:58

that is from the REPL?

tianshu10:01:25

No, both are not. write it in the file, after compiled, reload the browser.

tianshu10:01:59

(defn foo [] (throw ...))
(foo)
The code looks like this, nothing more.

thheller10:01:00

errors while loading are problematic

thheller10:01:08

don't trigger that while loading

thheller10:01:16

don't do anything while loading in general

thheller10:01:57

(defn foo [] (throw ...))

(defn ^:dev/after-load test-me []
  (foo))

thheller10:01:03

try that. maybe thats better

tianshu10:01:11

tried, the result is basically the same

tianshu10:01:50

there is a difference, the stacktrace for ex-info becomes much longer

tianshu10:01:59

but it's still meaningless for debug

thheller10:01:43

hmm right thats still during load

tianshu10:01:17

and this one is for js/Error.

thheller10:01:26

(defn foo [] (throw (ex-info "foo" {:x 1})))

(js/setTimeout foo 1000)

thheller10:01:34

this shows the correct trace

thheller10:01:52

I don't know why ex-info behaves that way. nothing I can control or shadow-cljs does to it.

tianshu10:01:33

yes, this show the correct trace

tianshu10:01:27

I think I need to take a look at how it behavior in other environment, in cljsbuild

thheller10:01:08

the loading is different so you'll probably get a different error

thheller10:01:27

you can try setting :devtools {:loader-mode :script}

thheller10:01:44

that loads things like other CLJS would and may throw a better error

thheller10:01:53

just don't throw errors at load time and you'll be good 😉

tianshu10:01:29

I found this because I tried to use some spec, a library called speced.def use ex-info for it's error.

tianshu10:01:02

I found cljs.main doesn't have this issue.

thheller10:01:31

and did you try the different :loader-mode?

tianshu10:01:40

with :loader-mode :script it works correctly.

tianshu10:01:23

ohhh, maybe it's because the cljs-devtools...

tianshu11:01:11

The ExceptionInfo has a field for stacktrace, without devtools you get found the key :stack.

tianshu11:01:55

is that because ExceptionInfo should extends something to make it display correctly. But when the error raised, this haven't been done.

thheller11:01:30

if you trigger the error during load then :loader-mode :script is basically what other CLJS does

thheller11:01:54

the "optimized" :loader-mode :eval (the default) loads things differently and thus may change the stacktrace

thheller11:01:11

exceptioninfo does extend error and stuff

thheller11:01:30

I don't know why the error is displayed differently ... I can only tell you that loading is different