Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom formatter for ex-info thrown by cljs.spec #23

Open
olivergeorge opened this issue Jul 29, 2016 · 8 comments
Open

Custom formatter for ex-info thrown by cljs.spec #23

olivergeorge opened this issue Jul 29, 2016 · 8 comments

Comments

@olivergeorge
Copy link

olivergeorge commented Jul 29, 2016

Currently it's quite tricky to get good output from cljs.spec. Reason being that the ex-info thrown includes the full spec commentary in ex-message. This includes the serialised val which failed. In my case this can fill the console many times over.

Alex Miller recommended catching these exceptions and using the ex-data to present the spec nicely. (e.g. don't print the ex-message to the console). This would be fine except it's difficult to catch all errors due to the nature of how UI code executes (react render loop, re-frame dispatch queue, callbacks)

How about automatically detecting and pretty formatting ex-info errors thrown by cljs.spec?

@darwin
Copy link
Member

darwin commented Jul 29, 2016

I like your idea. But how do you think cljs-devtools could implement this without this feature being framework-specific?

@darwin
Copy link
Member

darwin commented Jul 29, 2016

Ok, thinking about this more. We could install window.onerror handler as we do with sanity hints[1] and do some magic there. But if "framework" catches the exceptions, we are out of luck.

[1]

(defn install-type-error-enhancer []

@olivergeorge
Copy link
Author

That sounds like a good approach.

I guess the other possibility is to extend IFormat for ExceptionInfo and use ex-data to enable special treatment.

darwin added a commit to binaryage/cljs-devtools-sample that referenced this issue Aug 3, 2016
@darwin
Copy link
Member

darwin commented Aug 3, 2016

To keep the ball rolling, I have just tested ExceptionInfo behaviour[1].

Currently cljs-devtools has pretty nice behaviour, it presents the error printed with IPrintWithWriter protocol[2]. The implementation is questionable because they are re-implementing clojurescript map printer in there, but that is not essential to our issue at hand.

I think nothing is stopping you overriding IPrintWithWriter on ExceptionInfo and doing something better there (e.g. abbreviating long messages).

But I agree that we could do even better job with IFormat. We could reuse string abbreviation logic already implemented[3] in devtools and present other parts as expandable data.

[1] binaryage/cljs-devtools-sample@6422ec1
[2] https://github.com/clojure/clojurescript/blob/e2db5d9ff8cb6a099ebc2a8cd379385bf4649b38/src/main/cljs/cljs/core.cljs#L10283-L10286
[3]

@darwin
Copy link
Member

darwin commented Aug 3, 2016

btw. here is how it looks currently:

@darwin
Copy link
Member

darwin commented Aug 3, 2016

Actually this ExceptionInfo is not a fully working CLJS type, so cljs-devtools do not treat it correctly under all circumstances.

I went down the rabbit hole and proposed a solution upstream:
http://dev.clojure.org/jira/browse/CLJS-1722

Let's wait for its resolution before moving forward.

@olivergeorge
Copy link
Author

Interesting. Thanks. (I'd love to know what Bruce is thinking about presenting spec errors. Can't help but think he'll be the trendsetter.)

@arichiardi
Copy link

This would be a killer feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants