Fork me on GitHub
#expound
<
2020-11-19
>
bbrinck00:11:53

I’m wondering if this realistic in practice: usually with CLJS, you wouldn’t call the result from the top-level like that

bbrinck00:11:24

Rather, you’d like define the namespace, then the loading page would kick off some “main” function, which would then eventually call result

bbrinck00:11:06

And I generally wouldn’t expect hot-reloading to actually run code like result, but rather just reload all your functions, etc

bbrinck00:11:50

I realize that’s not a great answer, but I’m wondering if in practice what you have is actually “working” for a realistic use case

bbrinck00:11:27

In any case - I think this is fundamentally something I don’t understand about shadow or CLJS or onerror handlers.

bbrinck00:11:22

I’m far from the expert on those topics 😦 , so my advice is maybe to ask in #clojurescript and see if anyone has solved this. I am 99% sure this doesn’t relate to Expound though - you could reproduce the same problem by omitting the call to (set! spec/*explain-out* expound/printer) and I expect you still wouldn’t see a plain-ole spec error printed

bbrinck00:11:23

Or, even more explicitly, if you changed your code to be something like this

(defn error-handler [message url line column e]
  (print "???????????????????????????????????????????")
  (js/console.error e)
  (print (repl/error->str e))
  true)
My guess is you could repro (that is, you wouldn’t see the ???????) without any interaction w/ Expound

neilyio00:11:55

Yes you're right, it has nothing to do with whether Expound is being called. It's that (set! (.-onerror js/window) error-handler) doesn't seem to take effect right away.

neilyio00:11:07

I'll look into that. I guess I have two one parting questions, if you don't mind!

neilyio00:11:42

1. Why do I see <filename missing>:<line number missing> at the top of the Expound error from my screenshot? Those would be awfully useful to have.

bbrinck00:11:48

Good question! As of right now, CLJS doesn’t include this information in the spec failure data that is passed to Expound

bbrinck00:11:28

If you expand the error data you see under :data, I think you’ll see a :caller key, but it doesn’t include file or line number info 😞

neilyio00:11:45

Well, that's my new favourite CLJS issue to track. Can't wait for that feature.

👍 3
neilyio00:11:10

@U08EKSQMS thanks so much for keeping me in this today. I would have fully given up without being able to talk through it with you.

bbrinck00:11:39

No worries, happy to help in any way I can!

bbrinck00:11:41

If you figure out the core issue with the handler, let me know and I can update the README

neilyio18:11:50

@U08EKSQMS It's looking like a part of the issue was shadow-cljs, which apparently silently catches errors when it first loads the code. Nothing to do with expound. Thanks again for yesterday!

bbrinck18:11:14

Nice find! Glad to hear you figured it out.

neilyio19:11:33

Another mistake I was making yesterday is that I didn't realize that I needed to call spec.test/instrument again after a re-load... That's why what I was seeing felt so inconsistent!

bbrinck19:11:52

Ah, yes. I think that problem is one of the main things that Guardrails is trying to solve

bbrinck19:11:53

I haven’t used Guardrails but I remember that was mentioned in the rationale

neilyio00:11:41

2. Even with the setTimeout call, I still can't get the Devtools error formatter to work. Does window.onerror also need to be set for that, or should this code (from the README) be enough? EDIT: Disregard this. I've realized it does indeed work, however only with setTimeout. I get the result from the photo below.

👍 3