core.async: throwing an exception into the channel

[Alice]

It would be nice to have a function throw>! that puts an exception into the channel and throws it when taken, so that I can write

(let [c (chan)]

  (go (throw>! c (Exception.)))

  (go (try

        (prn (<! c))

        (catch Throwable t

          (prn "exception")))))

instead of

(let [c (chan)]

  (go (>! c (Exception.)))

  (go (try

        (let [res (<! c)]

          (if (instance? Throwable res)

            (throw res)

            (prn res)))

        (catch Throwable t

          (prn "exception")))))

[Timothy Baldridge]

The position of core.async is to not specify how exceptions should be done (instead leaving it up to the user). So if that method works well for you, write some macros and use it!

Other methods may be the use of supervisor channels. In this model, go blocks that die would enqueue the exception into a global (or shared) channel and the go block would then be re-started by a monitor process.

Both methods (and may more) are supported by core.async...it simply doesn't care how you handle exceptions, but it is up to you to specify how they are handled. 

Timothy

--
--
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
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
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Alice]

throw>! is an explicit operation, and there's no special channel states involved. It's passing an exception like other data that just automatically throws it when taken. So it won't hurt anybody. You can use it when you need it, you can ignore it if you don't need it. Yet, it makes using async functions look almost identical to the sync functions.

[John D. Hume]

I think I'd rather see separate functions or macros for consuming from a channel with the "maybe throw" behavior rather than having the standard consume form(s) come with that feature (or threat, depending on whether you want it). At that point you're back to the earlier advice to wrap core.async to fit your approach.

As new as core.async is to the Clojure community, it seems premature to build in an error-handling approach that may turn out not to be appropriate for many users.

[Sean Corfield]

My first thought was:

Since channels can have arbitrary values, how would you distinguish
your magical "thrown" exception value from an exception value put into
a channel for normal delivery? And no matter how you annotate that,
it'll still just be a regular value. So the only way you could have
the behavior you want would be to add special logic into every get
operation (and put operation, probably) so everyone would pay for a
feature that few will likely use...

(my second thought was "Why don't get operations just get updated to
throw if they get an exception value from the channel anyway?" but I
quickly realized this was the exact same problem!)

Sean

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)