You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent updates in cljs removed the explain-out string from exception messages. This means exceptions thrown by instrument will not contain a nicely formatted string even if all the instructions for setting up expound have been followed (eg. setting up s/*explain-out*).
These changes to cljs were made with the intention that exceptions should contain only data, and leave formatting/printing to the edges of the system, eg. by a REPL. To help with this, we have the cljs.repl/error->str function, which handles printing of exceptions in a general way (not only spec errors).
What does this mean for the browser? Well, to start, we'll find that exceptions have become less informative than they used to be, until we somehow leverage these new tools to make them meaningful again. There may be numerous approaches to this, each with their own tradeoffs.
a couple of approaches to consider:
print all uncaught exceptions using repl/error->str using a global error handler:
extend the ExceptionInfo type to always rely on the repl error->str function, so that errors you print in your own try/catch blocks are also formatted:
re: (3), here's a snippet for adding a custom formatter to the Chrome devtools console that will use repl/error->str to format any ExceptionInfo encountered:
Recent updates in cljs removed the
explain-out
string from exception messages. This means exceptions thrown byinstrument
will not contain a nicely formatted string even if all the instructions for setting up expound have been followed (eg. setting ups/*explain-out*
).These changes to cljs were made with the intention that exceptions should contain only data, and leave formatting/printing to the edges of the system, eg. by a REPL. To help with this, we have the cljs.repl/error->str function, which handles printing of exceptions in a general way (not only spec errors).
What does this mean for the browser? Well, to start, we'll find that exceptions have become less informative than they used to be, until we somehow leverage these new tools to make them meaningful again. There may be numerous approaches to this, each with their own tradeoffs.
a couple of approaches to consider:
repl/error->str
using a global error handler:ExceptionInfo
type to always rely on the replerror->str
function, so that errors you print in your own try/catch blocks are also formatted:augment the console itself to use
cljs.repl/error->str
to format errors - this would be the domain of tools like cljs-devtoolspatch/extend tools to (optionally) include formatted messages in exceptions
The text was updated successfully, but these errors were encountered: