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 clojure.lang.PersistentList$EmptyList@1
(form-init8401797809408331100.clj:2)
m is not a map!
expected: (map? m)
actual: (not (map? []))
AssertionError Assert failed: (is (map? m) "m is not a map!") user/get-key
(form-init8401797809408331100.clj:1)
This is great for repl use, but it does side-effect (the printed error) and
doesn't return anything structured. It's suited to development-time human
use rather than runtime or machine-use.
I see the potential for a macro which rethrows the assertion errors as
something like ex-info exceptions (i.e. something with structured data.)
That would fill runtime or machine-uses better (or structured logging?),
but I'm not sure that fits with the spirit of pre/post conditions in the
first place. After all, these do raise Java AssertionErrors, which are not
meant to be recoverable.
On Tuesday, March 29, 2016 at 4:19:12 PM UTC-5, Alex Miller wrote:
>
> (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? 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. 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 more precise information, like you said, that
>>> AssertionError could also throw up class/file information, etc. that a
>>> debugger could use. I would guard against designing these things to
>>> accomodate a context outside of it's execution scope. In the ideal
>>> functional world, the input and output are wholly localized. Any
>>> Error/Exception thrown can be consumed or chained to give very precise
>>> failure reasoning.
>>>
>>>
>>> As for how that would fit into the entire exception chain, that's still
>>> being thought (see here
>>> <http://dev.clojure.org/display/design/Error+Handling>). There are
>>> already a few approaches, and I think this (see here
>>> <http://dev.clojure.org/display/design/Error+Handling+Comparisons>) is
>>> the context of how the core team is approaching this problem.
>>>
>>>
>>> Cheers
>>> Tim
>>>
>>>
>>> On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar <kumar.s...@gmail.com>
>>> wrote:
>>>
>>>> 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 "`m` -- Expected: map, Found: vector [:foo :bar]"
>>>> so that I can debug it quickly.
>>>>
>>>> Pre-conditions and Post-conditions are a valuable debugging aid, and
>>>> to enable that we need very precise information. Unfortunately passing
>>>> a string error message cannot encapsulate enough error context. A more
>>>> complex example can be where the correctness of input must be
>>>> determined collectively (in association with other args) -- in those
>>>> cases one can only fall back on comparing input values and raise
>>>> IllegalArgumentException accordingly.
>>>>
>>>> Regards,
>>>> Shantanu
>>>>
>>>> On Jul 11, 10:40 pm, Timothy Washington <twash...@gmail.com> wrote:
>>>> >
>>>>
>>>
>>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
