Care to share an example? :)

Two that I've had in the last hour.

; The result object failed to print. It is available via *1 if you want to interact with it.
; 
; The exception was: 
; 
; Error: function(x,y,z,var_args){
; var args = var_args;
; switch(arguments.length){
; case 0:
; return cljs$core$epn__0.call(this);
; case 1:
; return cljs$core$epn__1.call(this,x);
; case 2:
; return cljs$core$epn__2.call(this,x,y);
; case 3:
; return cljs$core$epn__3.call(this,x,y,z);
; default:
; var G__14480 = null;
; if (arguments.length > 3) {
; var G__14481__i = 0, G__14481__a = new Array(arguments.length -  3);
; while (G__14481__i < G__14481__a.length) {G__14481__a[G__14481__i] = arguments[G__14481__i + 3]; ++G__14481__i;}
; G__14480 = new cljs.core.IndexedSeq(G__14481__a,0,null);
; }
; return cljs$core$epn__4.cljs$core$IFn$_invoke$arity$variadic(x,y,z, G__14480);
; }
; throw(new Error('Invalid arity: ' + arguments.length));
; } is not ISeqable

; The result object failed to print. It is available via *1 if you want to interact with it.
; 
; The exception was: 
; 
; TypeError: (new cljs.core.Keyword(...)).cljs$core$IFn$_invoke$arity$1(...) is null

The main value of an error is its full stacktrace, not its direct message. Without a stacktrace, things like NullPointerException or ClassCastException would also be completely useless.

Can I get the strack trace in Calva ? These messges are all I'm seeing my REPL. WHen I use *1 like it says I just get the same error message repeated.

What about *e ?

> No idea what either of them was trying to tell me Things that are clear to me: • You were using a REPL (that "*1" is the most clear indication) • You tried to evaluate something • The REPL was trying to print the result of that something (not via print and its friends but via the "P" part of "REPL") • That failed because of an underlying exception The last point also means that that particular error can only be as clear as the underlying error in terms of helping the user figure out what's going on and how to fix it. The first error is quite clear if you remove the fluff: "Error: function(...) {...} is not ISeqable". So you were trying, directly or indirectly, to convert a function to a seq. The stacktrace should point to where exactly that has happened. What's unclear is what that function is. But we can see that it's a multi-arity function that uses some function called epn in the cljs.core namespace (not necessarily at the top level). Looking at the sources of cljs.core, we can see that the only mention of epn is inside every-pred. So (every-pred ...) was used in the place of a collection. The second error is about the result of using a keyword as a function on something being null. Again, only the stacktrace would be helpful here.

> WHen I use *1 like it says I just get the same error message repeated. Because *1 is bound to the result of the most recent computation, not to the error. The error message means that you can use *1 to interact with that result and study it programmatically instead of relying on the "P" part of "REPL".

thank you for that! that's really helpful. And I appreciate you taking the time to help and type that out.

No problem. :) Feel free to post any other cryptic-looking error messages. CLJ/S error messages are a bliss compared to what C++ with templates or TypeScript can sometimes output. :D

Errors in Clojure are horrible. Errors in ClojureScript are atrocious. Errors in ClojureScript with React-Native make me feel like I'm hunting lions with stones for weapons 😢

By the way, even with source maps things don't get much better - in my new version of Chlorine I'm studying a way to disable or enable source maps because there are moments they send you to the wrong function...

But if it helps, when you have a "weird JS code is not sequable" or things like that know they you're probably trying to use a function as a collection or some other protocol that functions don't implement

Or... you can try ClojureScript Storm, from the FlowStorm project to inspect the last exception for you (it usually gets great results)

> even with source maps things don't get much better They usually do with pseudonames enabled during compilation.

Well, my experience with source maps is that they most often than not map things to the wrong place, and that if I open the pseudo-names JS file, I get a better insight of what's failing than using the source mapped file/row

But that's in node.js target, I basically never do CLJS for the browser