Leonardo, that's an interesting solution, thanks for writing it out and
giving me some food for thought.
My thought process was that at this point I have a pure API that either
gets the right inputs or it simply does nothing. As in, no helping messages
about what went wrong, no attempt to do recovery. Some claim that for
security purposes errors encountered by the API should be as opaque as
possible to leak few internal details, so that's vaguely the direction I'm
going in at this point, even though you lose on the development front.
I'd love to know your expert opinion on this, since you wrote Bouncer: say
you're in the situation I listed above, where you don't care about nice
error handling, you just want to give the caller a 400 if the input is
incorrect. Would you still go the route where the validator function
returns a list of errors? My concern is that now I have to have additional
checks in place in my controller for whether the model save returned a list
of errors, which will regardless ultimately result in a 400 status code.
Thanks!
(BTW, your blog is great, great content)
On Friday, August 16, 2013 7:28:51 PM UTC-7, Leonardo Borges wrote:
>
> I would prefer not throwing an exception in the case of a validation.
>
> Say your validation function returns a vector or the first argument
> contains validation errors if any and the second contains the original map:
>
> (validate my-map) ;; returns [{:errors '("blah")} original-map]
>
>
> Then a neat way to write your function, taking advantage or core.match[1],
> would be this:
>
> (defn my-fn [my-map]
> (match (validate my-map)
> [{:errors errors} original-map] (handle-errors)
> [_ original-map] (save original-map)))
>
> This is my personal preference. It's concise, elegant and idiomatic in
> languages that support pattern matching.
>
> If you'd rather not use core.match for whatever reason, I'd still opt out
> of throwing an exception. The function would just need a little bit more
> code to simulate the behaviour above.
>
> [1]: https://github.com/clojure/core.match
>
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Sat, Aug 17, 2013 at 12:08 PM, Alexandr Kurilin
> <al...@kurilin.net<javascript:>
> > wrote:
>
>> Let's hypothetically say I have a Ring application and I'm performing
>> some validation on the input map I receive as part of a POST request. The
>> validate function throws an exception if anything's wrong with the input.
>> The exception is caught in the middleware and turned into a 400 code
>> response.
>>
>> I could do either:
>>
>> (-> input
>> validate
>> save)
>>
>> or I could do:
>>
>> (do
>> (validate input)
>> (save input))
>>
>> The former doesn't really buy me anything, since a new version of input
>> would never be returned by validate. It is however "side-effect free" in a
>> way?
>> The latter is probably less idiomatic, but makes it obvious that input is
>> not changing as part of the evaluation.
>>
>> What would be the more elegant way of handling this? Is the do block
>> approach somehow inferior?
>>
>> Thanks!
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> 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+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
--
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/groups/opt_out.
