The supervision decider is used for specifying if the stream is supposed to
be completed with failure (stop) or discard the exception and continue
anyway (resume, restart). What you describe is that you want to convert the
exceptions to ordinary stream elements. That is not done with a decider.
You must model this in your types, e.g. using Either[T, Int] or Try[Int] ,
then you can use the ordinary future combinators to map and recover the Int
and exception into that type.

Regards,
Patrik

On Mon, Aug 24, 2015 at 11:45 PM, Alexander Zafirov <
[email protected]> wrote:

> Hello,
>
> I'm uncertain whether this is the correct place for my question since it
> falls in the middle between Akka Streams, Slick 3.0 and Futures in Scala
> but I will give it a shot. Please excuse me if you think otherwise.
>
> First about the scenario. I have a flow whose purpose is to create some
> abstractions, persist them in a single transaction into a postgres db and
> then forward a result to a sink.
>
>    - From reading about error handling in the Akka Streams docs I
>    understood that if an exception occurs it will propagate to the decider
>    where it should be dealt with so that we keep the data flowing and not
>    block the stream. The decider works with Throwable.
>    - With Slick 3.0 your query results to the db result in Futures. That
>    being said I wanted to model failure as a state so I made a
>    PartialFunction[Throwable, T] where T extends Throwable which will be
>    called on recover. The problem is that the result of the query is
>    Future[Int] so when you do future.recover(partialFunction) the type that
>    comes out is Future[Any].
>    - In the flow I get that Future[Any] and hope that if it blows up the
>    decider will pick it up and act accordingly in case of T.
>
> I don't like this implementation. I'm looking for some suggestions on
> best (or at least better) practices so that I can work this out. If you
> find this too involved then I would appreciate help on the following
> general questions:
>
>    1. Is the decider the "go to" abstraction for all types of exceptions
>    e.g. db related, arithmetic exceptions, etc.?
>    2. If not - what should propagate to it?
>
> Thanks in advance!
>
>
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>>>>>>>>>      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.

Reply via email to