On Wed, Jul 15, 2015 at 9:20 AM, <[email protected]> wrote:
> Sorry. I still cannot grip the point on how to pass errors or maybe > exceptions down the stream in a neat way without stopping the stream. > Use Try, Either, Option or any other (possibly self-defined) disjoint union type. > Swallowing errors (including programming faults) wouldn't be an option > since its required for nearly all circumstances to send an appropriate > reply to the client. > > Actually I wouldn't like to pass an error down through all stages where I > have to teach all stages - additionally to their business logic - how to > pass upstream errors downstream. Leave aside the runtime behavior when > passing an error through possibly lots of stages via message passing when > its clear it should appear only in the end stage. > This is no different for "normal" code. > > Forming a graph for error paths would be quite complex. > > The for comprehension way would not work. I can understand this due to the > really good picture from Johannes: > >> However, streams are different in another way: a Flow[T, U] is more than >> just a function T => U, it's more like a T => Seq[U] that can create any >> number of results for any input element. >> > > So one option is left. Break out of the stream either via exception > handler mechanism or by having an error handler actor/object passed into > every stage? > -So far I don't know how to pass a reference into a materialized > instance of a flow stage. > -Exception handling (supervision/decider) is either coupled to a > materializer or to a stage not to stream (there were stream segments in > past version?). > -When doing exception handling via supervision/decider I loose the > context means the current input value causing the problem. In order to be > able to complete the request I need to pass a request context down the > stream so my stages would always look like Flow[(Val, ReqCtx), ..., ...]. > In order to complete with error I need the request context in the exception > handler too. > One way to achieve this is to enrich the exception info with the request > context. Which means catch all exceptions in all stages and wrap them into > an enriched one :-( > > Should that be really all options I have? Maybe I want to do the wrong > thing? > Again, this is no different than for normal code, exceptions abort the current processing. If you want to continue on an exception, you need to model your processing accordingly. > > If it would be Christmas my current perhaps childish wish would be some > kind of exception handler (actor) that materializes with the stream (or > parts of them) where in case of exception it gets the error causing input > value passed along with the exception and perhaps the stages name. > If you only need it for debugging there is already debug logging settings to enable for stream. > > Am Dienstag, 14. Juli 2015 17:06:58 UTC+2 schrieb √: >> >> >> >> 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? >> > > ?, even a Try cannot return an object of T in case of an exception it > would just throw the exception which it contains. > >> >> >>> - 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. >> > > Discard errors is no option in my case. > >> >> >>> 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. >> > > Stack unwinding is quite different to what is done with streams or actors > I guess. I did http server programming the spring/servlet way for quite > some years. The programming model thread per request is really comfy when > it comes to error/exception handling. You can place exception handling code > in a central place. And in case of an exception you still have the request > context at hand in order to send an appropriate error reply. > >> >> 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, >> √ >> > > 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, √ -- >>>>>>>>>> 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.
