Hey,
I really like the idea of pulling out exception handling from the function
bodies. The try catch form has always bugged me a little bit.
One thing that worries me though. While this is fine for examples where you
simply log the exception and move on, what if you need to do something more
complicated with the actual data? Say for example you need to queue/trigger
a retry, you no longer have your local bindings to work with so you'd have
to go back to a normal try/catch (disclaimer - didn't read the paper, just
going off the code and your comments)
Couple of thoughts on the code:
If you want to attach the error handlers to a particular function var
(task), why not alter-meta and add the handler function there rather than
maintaining a separate atom? Given that the deftask is pretty much
redundant anyway, I don't really see the point in making the distinction.
Plus I think your current code is dropping namespaces, causing potential
future explosions?
I'd be tempted to make a supervise function which simply takes a handler
map and do away with the macros altogether, you can still def handlers at
the top level if you want to re-use them, but you could also merge sets of
handlers if you wanted, or pass in handlers which have some idea of what
task you're supervising because they have been declared in the same lexical
scope, e.g.
(let [currenturl "..."]
(supervise {ConnectionError (fn [e] (queue-retry! currenturl))
NotFoundError (fn [e] (log "failed:" currenturl
(.getMessage e))}
fetch-url currenturl :timeout 10))
or your example would look like:
(defn divider [a b]
(/ a b))
(def div-zero-handler
{ArithmeticException (fn [e] (println "Cannot divide by zero"))})
(def npe-handler
{NullPointerException (fn [e] (println "..."))})
(def supervised-divider (partial divider (merge div-zero-handler
npe-handler)))
(supervised-divider 10 0)...
Which I would argue is a lot more idiomatic and flexible. I think macros
are overkill and unnecessary complexity here, you just need a supervise
function which takes responsibility for catching errors and lets you re-use
handlers
Adam
On Friday, December 28, 2012 7:14:34 PM UTC, Michael Drogalis wrote:
>
> Hey folks,
>
> After watching The Language of the System and being directed to Joe
> Armstrong's paper on error handling, I concurred that his approach is
> fantastic. I really wanted the same thing for more rudimentary operations,
> like file handling. So I wrote Dire
> https://github.com/MichaelDrogalis/dire
>
> The pros are of this are that error handling code is removed from
> application logic and it is not order complected.
> The cons are that tasks are not as strongly isolated as they are in
> Erlang. Also, because it is so simple (16 lines),
> there's no way for a supervisor to "restart" a child task. (Yet, I guess.
> Ideas?)
>
> Can such a thing be useful in a non-distributed environment? Or does this
> look like a hassle to use?
>
>
>
--
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
