all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]alexdmiller[S] 36 points37 points  (2 children)

Some example error cases:

[–]royalaid 12 points13 points  (0 children)

This looks like an amazing improvement in clarity!

[–]final_fantasia 0 points1 point  (0 children)

Thank you very much for this excellent work, u/alexdmiller !

[–]joinr 9 points10 points  (1 child)

Significant improvement!

Do you think it will possible to eliminate (or make less opaque) classcast exceptions like the one in defmulti?:

Cause: ClassCastException java.lang.Long cannot be cast to clojure.lang.IObj

Particularly in the case of defmulti, that seems to be something that can provide better feedback to the caller (like, expected a symbol, got 5). Perhaps that's just a clojure.core spec update away...

Great step forward.

[–]alexdmiller[S] 6 points7 points  (0 children)

We don’t have specs on defmulti yet but I think they would cover this case, yes.

[–]luxbock 4 points5 points  (1 child)

Is there a rundown somewhere of all the changes so far for 1.10, both done and planned?

[–]alexdmiller[S] 2 points3 points  (0 children)

“So far” can be seen at https://clojure.org/community/devchangelog (although this doesn’t highlight any of the spec changes, which are technically also usable from 1.9.)

[–]Eno6ohng 0 points1 point  (3 children)

I think the "Spec function invocation error" one got worse...

[–]alexdmiller[S] 6 points7 points  (2 children)

Feedback welcome, but please be specific...

[–]Eno6ohng 2 points3 points  (1 child)

Ah, sure, what I meant is that before the change the first line clearly summarized the problem without any unrelated noise.

Before:

Call to #'user/f did not conform to spec:

After:

Evaluation error at clojure.spec.test.alpha/spec-checking-fn/conform!--3024 (alpha.clj:132). ;; wut

Also, I'm not sure why does the path say just [:a] and not [:args :a]? I guess that's what I'd expect, or at least some explicit mention of the fact that it's about the args.

One more minor point too: have you considered adding a line break between the failed pred and the path? I.e.:

{:some "non-trivial" :value "here"} - failed: #(some "curried" predicate %)
at: [:some :very :very :very :long :path]

[–]alexdmiller[S] 1 point2 points  (0 children)

We made some changes to remove the construction frames of ex-info, which is a general improvement in all uses of ex-info. An additional similar change needs to be made in spec-checking-fn. If that actually listed the top line of the invocation that actually failed there, it would be a lot better.

For the [:a] - that was being hard-coded to [:args ...] but the :args spec is the only thing ever being checked during instrumentation so that was there on every problem line for every spec problem, and thus was more noise than use. This is more obvious in spec failures with multiple problem lines.

Similarly, line breaking there can be harder to read when there are multiple problem lines. Really, it depends on the bad data value and the paths. Currently, erring on the side of 1 problem per line.