Czytam Akka Futures Guide i widzę to zdanie:Akka mapTo kontra asInstanceOf
Należy również zauważyć, że w przyszłości zwracane przez aktora jest Future [Każdy] od aktorem jest dynamiczna. Z tego powodu AsInstanceOf jest używany w powyższej próbce. Przy użyciu non-blocking lepiej jest użyć metody mapTo bezpiecznie spróbować rzucić przyszłości oczekiwanego typu
Dlaczego mapTo lepiej użyć niż asInstanceOf dla non-blocking przyszłości?
Problem z asInstanceOf tutaj jest, że będzie to po prostu rzucić na cokolwiek chcesz
scala> val f = future { 2 }
f: scala.concurrent.Future[Int] = [email protected]
scala> f.asInstanceOf[Future[String]]
res9: scala.concurrent.Future[String] = [email protected]
scala> f.asInstanceOf[Future[List[String]]]
res10: scala.concurrent.Future[List[String]] = [email protected]
scala> res10.value
res15: Option[scala.util.Try[List[String]]] = Some(Success(2))
ze względu na rodzaj skasowaniem JVM nie zna konkretny rodzaj wewnętrznej wartości. Jeśli zamiast tego użyjesz mapTo, będzie on rzutował bezpośrednio na wartość, gdy tylko będzie dostępna, a w przypadku typu niezgodnego, odzyskasz nieudaną przyszłość.
scala> f.mapTo[List[String]]
res11: scala.concurrent.Future[List[String]] = [email protected]
scala> res11.value
res14: Option[scala.util.Try[List[String]]] = Some(Failure(java.lang.ClassCastException:
Cannot cast java.lang.Integer to scala.collection.immutable.List))
To nie tak dużo, że mapTo jest lepszy w tym przypadku, jako że asInstanceOf jest niedostępny: ich przykładem z asInstanceOf używa go do oddania wynik z Any do String, ale z non-blocking przyszłości, nie masz jeszcze wynik, nawet jako Any. Zamiast tego masz numer Future[Any] i musisz użyć jego metody mapTo, aby zamknąć go jako Future[String].