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 bit hacky.
On Tuesday, March 29, 2016 at 10:40:41 PM UTC+1, Francis Avila wrote:
>
> 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.
