expound

bbrinck 2020-11-19T00:00:53.075300Z

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

bbrinck 2020-11-19T00:01:24.076200Z

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

bbrinck 2020-11-19T00:02:06.077300Z

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

bbrinck 2020-11-19T00:02:50.078Z

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

bbrinck 2020-11-19T00:04:27.079200Z

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

bbrinck 2020-11-19T00:06:22.081500Z

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

bbrinck 2020-11-19T00:07:23.082500Z

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

neilyio 2020-11-19T00:11:55.083500Z

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.

neilyio 2020-11-19T00:14:07.083900Z

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

neilyio 2020-11-19T00:14:42.084700Z

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.

neilyio 2020-11-19T18:03:50.091300Z

@bbrinck 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!

bbrinck 2020-11-19T18:12:14.092100Z

Nice find! Glad to hear you figured it out.

neilyio 2020-11-19T19:21:33.092300Z

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!

bbrinck 2020-11-19T19:55:52.093300Z

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

bbrinck 2020-11-19T19:56:53.094100Z

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

neilyio 2020-11-19T00:16:41.086500Z

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.

👍 1
neilyio 2020-11-19T00:17:18.087200Z

bbrinck 2020-11-19T00:24:48.088500Z

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

bbrinck 2020-11-19T00:25:28.088700Z

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 😞

bbrinck 2020-11-19T00:26:24.088900Z

https://clojure.atlassian.net/browse/CLJS-2758

neilyio 2020-11-19T00:30:45.089500Z

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

👍 1
neilyio 2020-11-19T00:31:10.089700Z

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

bbrinck 2020-11-19T00:35:39.090300Z

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

bbrinck 2020-11-19T00:36:41.091100Z

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