Re: Reworking :pre condition to add an error message

2016-03-30 Thread Oliver George
I look forward to pre/post conditions becoming more helpful. Truss is a good example of how things can improve. I think part of the challenge is not making the code too messy. Here's a proof of concept of how metadata in the pre/post/assert expression could be used to craft nice messages:

Re: Reworking :pre condition to add an error message

2016-03-30 Thread Niels van Klaveren
Truss also has good support for :pre and :post conditions On Monday, July 11, 2011 at 7:40:48 PM UTC+2, frye wrote: > > Note: This message was originally posted by ' Shantanu' on

Re: Reworking :pre condition to add an error message

2016-03-30 Thread i . am
CLJ-1817 looks interesting. We’ve been achieving similar behaviour via `or` statements in `:pre/:post`: (defn somefn [x] {:pre [(or (map? x) (throw+ {:type ::bad-stuff :details ...}))]} ...) This way we were also getting more useful exception types than AssertionErrors, but it did feel a

Re: Reworking :pre condition to add an error message

2016-03-29 Thread Francis Avila
A wonderful hack I read about somewhere is to just use the clojure.test/is macro, which I now do all the time: (require '[clojure.test :refer [is]]) => nil (defn get-key [m k] {:pre [(is (map? m) "m is not a map!")]} (m k)) => #'user/get-key (get-key [] 0) FAIL in

Re: Reworking :pre condition to add an error message

2016-03-29 Thread Alex Miller
(zombie thread back from the dead... :) I think enhancements on :pre/:post are interesting. http://dev.clojure.org/jira/browse/CLJ-1817 seems like a good place to work on this. On Tuesday, March 29, 2016 at 4:02:25 PM UTC-5, Colin Taylor wrote: > > Would there be interest in a ticket in this?

Re: Reworking :pre condition to add an error message

2016-03-29 Thread Colin Taylor
Would there be interest in a ticket in this? Seems simple enough if (as above) putting the message under the :pre key is acceptable? On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote: > > I do think a simple String error message is all that the user of the > function should provide.

Re: Reworking :pre condition to add an error message

2011-07-13 Thread Timothy Washington
I do think a simple String error message is all that the user of the function should provide. From there, An AssertionError can throw up something along the lines of what you said - Expected… , Found… , Message. That would give enough information for reporting at least in a test framework. To get

Re: Reworking :pre condition to add an error message

2011-07-12 Thread Shantanu Kumar
As I am the culprit of having introduced it with a naive example, I'd better admit it may not be very useful in practical scenarios across a wide variety of use cases. For example, when there is an assertion error with message `m` should be a map 14 levels down the stack, I'd really wish it said

Reworking :pre condition to add an error message

2011-07-11 Thread Timothy Washington
Note: This message was originally posted by ' Shantanu' on the *Re: Clojure for large programs* thread. I took a look at Shantanu's macros, and I like the concept a lot. But I would prefer something baked into the :pre condition itself. The reason is that it just removes a layer of indirection.

Re: Reworking :pre condition to add an error message

2011-07-11 Thread Ben Mabey
On 7/11/11 11:40 AM, Timothy Washington wrote: Note: This message was originally posted by ' Shantanu' on the */Re: Clojure for large programs/* thread. I took a look at Shantanu's macros, and I like the concept a lot. But I would prefer something baked into the :pre condition itself. The

Re: Reworking :pre condition to add an error message

2011-07-11 Thread Timothy Washington
Yes, the :post is easily done as well. I just wanted to throw up a quick proof-of-concept. Tim On Mon, Jul 11, 2011 at 1:52 PM, Ben Mabey b...@benmabey.com wrote: ** On 7/11/11 11:40 AM, Timothy Washington wrote: Note: This message was originally posted by ' Shantanu' on the *Re: Clojure

Re: Reworking :pre condition to add an error message

2011-07-11 Thread Laurent PETIT
If this could integrate with existing efforts put on validation libraries, plus (optionnally) a way to customize the rendering of pre-condition errors, this could be great :-) Maybe just inverting things : if the precondition returns falsy, this could mean that there is no violated precondition.