On Tue, Jul 14, 2015 at 4:51 PM, <[email protected]> wrote:
> > > Am Dienstag, 14. Juli 2015 15:42:33 UTC+2 schrieb √: >> >> Hi Leslie, >> >> On Tue, Jul 14, 2015 at 3:34 PM, <[email protected]> wrote: >> >>> I see. >>> So no happy path programming while not loosing the error case with >>> reactive streams? This is a quite a bit disillusioning. Should be mentioned >>> in all those shiny reactive stream presentations ;-) >>> >> >> It's mentioned all the time afaik, onError is for out-of-band stream >> teardown, onComplete is in-band stream teardown. >> >> If one wants to track transient errors, the solution is to be honest >> about it and do it in the element type using something like Either or Try. >> > > This is exactly the point that is unclear to me. From 'classic' scala > programming I'm used to have Try[T] outputs. So far its clear. But how do I > pass it downstream? Currently I see two options: > 1. Pass the Try[T] as input into the next stage which just pass through > the error or evaluates new data. > - I can do this only for flow stages which are designed for it. Client > http requests via akka HttpExt Flow wouldn't accept a Try[T] the input > needs to be a (HttpRequest, T) > Which means that you need to decide what to do before passing it along to that. How is that different from how you'd need to deal with having a Try[T] and require to return T? > - Errors in early stages needs to be passed down through all stages > If they are transient you can discard them if the parts after it are not interested. > 2. Transform each error causing flow stage into a graph with std out for > the happy path and error out for the error path. > - Would quickly become complex and error prone. Forking after each > method invocation into a good and a bad path, I guess this was the point > why exceptions were invented. > As Johannes mentioned before, the current semantics is exactly that of normal code (exceptions thrown unwinds the stack and abandon work to be done after the cause of the exception. It should also be possible to hoist T => R Flows into Try[T] => Try[R] (passing thru failures from upstream to downstream) and Try[T] => R (dropping failures from upstream). > >> >>> >>> Is there some per stream exception handling mechanism instead which >>> would materialize with the stream? >>> I know the supervision/decider mechanism which is unfortunately per >>> materializer or per stage. >>> Leslie >>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: >>> http://doc.akka.io/docs/akka/current/additional/faq.html >>> >>>>>>>>>> Search the archives: >>> https://groups.google.com/group/akka-user >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Akka User List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Cheers, >> √ >> > > The use case I have in mind is an http server. There is a stream per > request type, let say "configure a dsl line". The stream is continuously > fed with requests from a REST client and produces continuously responses > which are sent back to the client. Inside the stream there are successive > http request/response stages for communication with a device. There is lots > of validation required here. And there is always a response required. > Can it be that infinite streams are troublesome by nature? So it would be > better to open one stream per request? Than the onComplete/onFailure way > would work. But it still feels unnatural to me to have a stream per request > pattern! > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, √ -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
