Hey Moe,
>
>>
>> into and pipe should probably be safe.
>
>
> I was thinking of a case where a function is returning the equivalent of:
>
> (async/onto-chan ... [1 2 (Exception.)])
>
> And the consumer wants to async/into [], obscuring the error from <?. It
> looks like you've defined <<? as an alternative.
>
> I have some distantly related code here:
> https://github.com/nervous-systems/glossop/blob/master/src/glossop/util.cljc -
> keyed-merge (when used with a/into {}) is a slightly different approach to
> <!*
Oh sure, I was so deeply troubled for the last weeks by this issue, that
I somehow thought you only ment how to compose nested channel operations
and totally missed your very valid obvious concern (Freudian weirdness
;) ).
Since as a user of core.async you are not obliged to take from a
channel, the throwing of exceptions depends on the manual usage of <?
and it will be trivial to swallow exceptions. This broke my first
requirement to match Erlang robustness, that all errors need to be
raised. You can always write:
(do (go-try (throw (ex-info "I will be lost." {}))) 42)
Your example is just one of many where an exception is somewhere turned
into a value and never rethrown. If you can control the places where
this is happening, for me in go-try, then you can at least track the
exceptions and untrack them when they are rethrown (back in the standard
exception handling mechanism). This is adding an outside error handling
mechanism. I then do polling in the supervisor for the tracked
exceptions and whenever one stays too long in the resting position
(becomes stale), I trigger the supervisor mechanism with it and restart.
I have thought a lot about it and at least this is safe and somewhat
reasonable. You can never miss deeply nested errors, which might be
stuck in some channels.
>
> Can you find constructs/cases I am missing?
>>
>
> I haven't taken everything in, though I think it'd be great if your channel
> operations were usable outside of the context of a supervisor, so pieces of
> the approach could be considered/adopted without going all-in.
Since I have to track all exceptions, you need to have a *super*
supervisor binding for the code to work (and you will later want to have
it in production setups to catch problems slipped out of explicit
supervision scope). I provide now a default supervisor, which for now
printlns errors to stdout so you can see them in the REPL (which is imo
also better than core.async printing stacktraces to stdout of the
nrepl-server through the thread pool).
Is this not modular enough for you? As long as you don't use supervisor
code and have no stale errors you will not hear from the default
supervisor and can minimally use go-try with <?. The biggest problem I
see in the opposite direction: All your code needs to use these macros
to be supervised, so I think there needs to be some error-handling
standard in core.async eventually to make libraries composable.
Christian
--
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.
