On Dec 2, 2011, at 1:29 PM, Phil Hagelberg wrote:
>> I was using defrecord for the first time, to create a type that I wanted to
>> throw+ via slingshot to signal errors from a library.
>
> For what it's worth, the main point of slingshot is removing the
> necessity of creating custom classes for exceptions, so this shouldn't
> be necessary in the first place.
Would you elaborate on this a bit more? I would greatly appreciate the
education!
Let's say I am writing some code that uses three different libraries (actiona,
actionb, and actionc) to accomplish its goals.
Each of these action libraries can generate an exception that indicates that
things did not go well for the user/client.
I'd like to write my code so that the try+ clause is the "everything works"
path, and that I then catch various errors that each of my actions may have
generated.
Assume that I need to distinguish between the three possible action exceptions,
and handle them completely differently.
If each of the (independently written) action libraries throws its own map,
then how do I distinguish between these maps, especially if they happen to use
identical keywords to report errors?
One reason I was/am attracted to the "each action library should define its own
error record type" I mentioned originally is that it makes distinguishing
between these different exceptions trivial:
(try+
(-> (actiona data)
(actionb)
(actionc))
(catch actiona-error ...)
(catch actionb-error ...)
(catch actionc-error …))
Perhaps putting multiple exception generating actions into one try+ is not the
recommended/idiomatic approach?
I guess I could be convinced of that, but at the moment, I really like
concentrating first on implementing the functionality of my app,
and then catching and dealing with all the errors at the top level.
I find code that for every call has to test or try/catch errors for every thing
it does is more painful to follow/read, but maybe that is just my
bias/limitation.
To take a random example, the library clj-http throws its normal response map
when the http response code it receives is not "unexceptional-status?"
So how do I catch that?
By looking for a key of :status?
That seems quite ripe for key name collisions, if there are more than one
action in the try block that could create an exception, and more than one
action generates a map with the keyword :status
Here is what I am doing right now:
(defn http-response-map?
[hrm]
(get hrm :status false))
(try+
(client/get url)
(catch http-response-map? {:keys [status headers body]} … ))
I had some confusion last night when I was not specific enough about the
exceptions I was catching,
and a catch of Object that I (in error) thought would only catch the last
remaining exception caught everything,
and something else that I didn't expect threw, and I didn't realize the problem
for a while….totally my fault,
but further motivation that catches be very specific about what they are
catching,
and I'd like to understand how best to do that without defining custom classes.
Best regards,
Don
--
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
