Am Dienstag, 14. Juli 2015 15:42:33 UTC+2 schrieb √:
>
> Hi Leslie,
>
> On Tue, Jul 14, 2015 at 3:34 PM, <[email protected] <javascript:>>
> 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)
- Errors in early stages needs to be passed down through all stages
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.
>
>
>>
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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.
