Suggestion - add name of the function where the spec failed to validation error report

[LiesbethW]

When I spec arguments of a function with a validation that occurs often throughout the codebase, it can be hard to find out what function I called with invalid arguments. I suggest to add the speced/defn that failed to the error report.

For example if now I call this function with a nil office id:

(speced/defn create-support-chat-flex-worker [db-conn
                                              ^:datomic/eid flex-worker-id
                                              ^:datomic/eid office-id]
 ...

Where you now get

-- Spec failed --------------------
Validation failed

  nil

evaluated from

  office-id

should satisfy

  pos-int?

-- Relevant specs -------

:datomic/eid:
  clojure.core/pos-int?

-------------------------
Detected 1 error

Would become something like

Validation failed

  nil

evaluated from

  office-id

in speced function

 link.stores.datomic-chat-store/create-support-chat-flex-worker

should satisfy

  pos-int?

-- Relevant specs -------

:datomic/eid:
  clojure.core/pos-int?

-------------------------
Detected 1 error

Even cooler would be if I also knew where this function got called from, but I can imagine that's a lot more involved.

[vemv]

Just to be clear, do you not get a stracktrace along with with these error reports?

I admit the error reporting (the Validation failed message which comes from Expound) and the stacktrace are disjointed, i.e. the message and the stacktrace can be printed in different places (different windows of your IDE) and at different times (5 seconds later, or interspersed with unrelated output).

But disjointed or not, the stacktrace should be there, which probably would address most of your pains. 95% of the times I don't get disjointed output. (Things that can cause it: running tests, concurrency)

Can you confirm?

Btw, the Expound error reporting is currently hacked (we with-out-str it and manipulate it). If/when bhb/expound#148 is addressed, it might be reasonable to add more handy fields to it, but meanwhile I'd preferably keep the hacking at a minimum.

--

Even cooler would be if I also knew where this function got called from, but I can imagine that's a lot more involved.

(This specific suggestion seems off since it'd largely duplicate Clojure's throw mechanism which already informs you of the stacktrace)

[thumbnail]

Addressed here: nedap/utils.spec#13

Make sure you're on utils.spec 1.3.0 or later, and you can set the stackframe property to show a (part of?) the stacktrace when a validation failed 🎉.

I personally embedded this in my ~/.lein/profile.clj

 :u.spec {:managed-dependencies [[com.nedap.staffing-solutions/utils.spec "1.3.0"]]
          :jvm-opts ["-Dnedap.utils.spec.print-stack-frames=5"]}