silent mapTo failure on bad cast?

[Sam Halliday]

Hi all,

I'm using pattern.ask quite intensively and this means using .mapTo[T] quite a lot.

I don't like this, as it means I've lost type safety.

However, things are even worse than that because it appears that if T is not what is actually received there is a silent error.

Am I correct, or is something else in my code swallowing the error?

Regards,

Sam

[Akka Team]

Hi Sam!

You sould get a failed Future with a ClassCastException as the reason.

-Endre

[Roland Kuhn]

22 feb 2013 kl. 16:41 skrev Akka Team:

> Hi Sam!
>
> You sould get a failed Future with a ClassCastException as the reason.

… unless your .mapTo[] happens to be aimed at a type which is modified by erasure (i.e. .mapTo[List[String]] will not give you immediate errors when used on a Future[List[Int]]).

Regards,

Roland

>
> -Endre
>
> --
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>> 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 akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[Akka Team]

> … unless your .mapTo[] happens to be aimed at a type which is modified by erasure (i.e. .mapTo[List[String]] will not give you immediate errors when used on a Future[List[Int]]).

Yes, I forgot that important piece of information :). The docs
explicitly state this: "Creates a new Future[S] which is completed
with this Future's result if that conforms to S's _erased type_ or a
ClassCastException otherwise." (emphasis by me)

-Endre

[Samuel Halliday]

Thanks - the types are usually Either[SomeFailure, SomeSuccess], that sounds like the problem.


--
Sam

[Samuel Halliday]

Is there a workaround?

--
Sam

[Akka Team]

Hi Sam!

In general you should not use type parameters in your messages between
actors as type erasure makes it impossible to match on the type
parameter.

-Endre

[Roland Kuhn]

Hi Sam,

having a Future[Either[...]] is a somewhat funny construction, because Future is already encapsulating a type union (namely T and Throwable, represented as Try[T], previously Either[Throwable, T]).

Apart from that—and expanding on Endre’s reply—I would highly recommend not to use generic data types as messages between actors and instead to create specific message types, e.g. if you want to reply with a List of Things, then don’t send List[Thing] but instead a case class wrapping a List[Thing]. This will help you understand the purpose of the List[Thing] in its context (e.g. wrapped in a ThingsToDoReply) and it also allows the compiler to help you in case of mistakes, e.g. exhaustivity checks in match expressions or when using the upcoming Typed Channels.

Regards,

Roland

[Samuel Halliday]

Oh, I know why we shouldn't be doing this - but a refactor at this stage is impossible. Any use of it is type unsafe imho.

Is it possible for the mapTo itself to be updated so that any runtime cast problems are caught?

--
Sam

[Roland Kuhn]

No, that is not possible, it is limited by how the JVM works.

[Alec Zorab]

<hijack>

On 22 February 2013 16:56, Roland Kuhn <goo...@rkuhn.info> wrote:

Hi Sam,

having a Future[Either[...]] is a somewhat funny construction, because Future is already encapsulating a type union (namely T and Throwable, represented as Try[T], previously Either[Throwable, T]).

 

Not sure about this one Roland - there are plenty of scenarios where I might ask another actor to validate something and I expect back either a validated instance of T or an explanation of why it's no good. Presumably you're not suggesting that my validating actor should be sending me back feedback via the error message of the Throwable?

</hijack>

[Roland Kuhn]

<hijacked status="back on track">

My response to that was the paragraph which you did not quote: send actor-specific message types, which also makes documentation of an actor’s message repertoire straight-forward.

<tangent>Future[Either[...]] can occur out of the desire to use for-comprehensions with a complex Future flow which requires sophisticated error handling, and my response to that has always been to use (short-lived) actors as soon as the Future-based version gets too complex and/or ugly.</tangent>

</hijacked>

<closing style="Regards">Roland</closing>

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Derek Williams]

Yep, I agree with Alec. I've been able to sneak scalaz in, and we've been starting to switch over to using Future[L \/ R]. Or even better, a wrapper equivalent to an EitherT[Future, L, R]  so it's still easy to work with the right hand side without flatMap gymnastics. It is working great. Now a Future that contains an exception is considered an unexpected exception and we have a separate channel for communicating normal failures.

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Derek Williams

[Roland Kuhn]

Hi Derek,

yes, monad transformer stacks are the “other” way to do error handling. The reason why I prefer actors is because that allows you to decouple the business logic flow from the failure recovery code where applicable, whereas your way ends up entangling both inextricably. Both are tools, of course, and the seasoned hakker will choose the best for each job :-)

Regards,

Roland