I’m wondering if this realistic in practice: usually with CLJS, you wouldn’t call the result from the top-level like that
Rather, you’d like define the namespace, then the loading page would kick off some “main” function, which would then eventually call result
And I generally wouldn’t expect hot-reloading to actually run code like result
, but rather just reload all your functions, etc
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
In any case - I think this is fundamentally something I don’t understand about shadow or CLJS or onerror
handlers.
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
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/ ExpoundYes 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.
I'll look into that. I guess I have two one parting questions, if you don't mind!
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.
@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!
Nice find! Glad to hear you figured it out.
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!
Ah, yes. I think that problem is one of the main things that Guardrails is trying to solve
I haven’t used Guardrails but I remember that was mentioned in the rationale
2. Even with the ?
EDIT: Disregard this. I've realized it does indeed work, however only with 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 enoughsetTimeout
. I get the result from the photo below.
Good question! As of right now, CLJS doesn’t include this information in the spec failure data that is passed to Expound
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 😞
Well, that's my new favourite CLJS issue to track. Can't wait for that feature.
@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.
No worries, happy to help in any way I can!
If you figure out the core issue with the handler, let me know and I can update the README