2.6 zio入门——对比Future
2.6 對比Future
本小節,我們可以通過比較Scala標準庫中的ZIO和Future來闡明到目前為止所學的知識。
在本書后面討論并發性時,我們將討論ZIO和Future之間的其他差異,但目前要記住三個主要差異。
2.6.1 一個 Future 就是一個正在運行的 effect
與ZIO之類的函數式作用不同,Future是對運行時的作用進行建模。 回到先前的一個示例,請考慮以下代碼段:
import scala.concurrent.Futureimport scala.concurrent.ExecutionContext.Implicits.globalval goShopping: Future[Unit] = Future(println("Going to the grocery store"))就像我們最初的示例一樣,一旦定義goShopping,此效果就會開始執行。 Future不會暫停對其中包裝的代碼的運行。
由于"做什么"與"怎么做"之間存在糾結,在Future顯得并不是那么強大。例如,就像在ZIO上一樣,能夠在Future上定義一個延遲運算符會很好。但是我們不能這樣做,因為一個Future一旦存在,它就已經開始運行,沒有機會再延遲計算。
同樣,在失敗的情況下我們也不能像ZIO那樣重試Future,因為Future并不是做某事的藍計劃,而是一種執行性的計算。因此,如果Future失敗,則無事可做。我們只能檢索失敗。
相比之下,由于ZIO effect是并發工作流程的藍圖,因此,如果執行一次該效果但失敗了,我們可以隨時嘗試再次執行它,或者執行任意多次。
這種區別特別明顯的一種情況是,每當您在Future上調用方法時,您就必須在范圍內具有隱式ExecutionContext。
例如,這是Future#flatMap的簽名,與ZIO上的flatMap一樣,它使我們可以編寫順序效果:
import scala.concurrent.ExecutionContexttrait Future[+A] {def flatMap[B](f: A => Future[B])(implicit ec: ExecutionContext): Future[B]}Future#flatMap需要一個ExecutionContext,因為它表示一個運行中的effect,因此我們需要提供ExecutionContext,隨后的代碼應在該ExecutionContext上立即運行。
如前所述,這將"要完成的工作"與"如何完成的工作"混為一談。 相反,我們所見的涉及ZIO的代碼都不需要執行程序,因為它只是一個藍圖。
ZIO藍圖可以在我們想要的任何Executor上運行,但是在實際運行效果之前,不必指定它(或者稍后,我們將看到如何 “lock” 效果以在特定 execution context 中運行,那些罕見的情況
您需要對此明確說明)。
2.6.2 Future的錯誤類型固定為Throwable
Future的錯誤類型固定為Throwable。 我們可以在Future#onComplete的簽名中看到這一點:
import scala.util.Trytrait Future[+A] {def onComplete[B](f: Try[A] => B): Unit}Future的結果可以是成功返回一個A,也可以是拋出Throwable的失敗。 當使用可能因任何Throwable失敗而遺留的舊代碼時,這可能很方便,但與多態錯誤類型相比,它的表達能力要低得多。
首先,通過查看類型簽名,我們不知道effect如何失敗或甚至是否會失敗。 考慮一下我們討論用Future實現的ZIO錯誤類型時所看的乘法示例:
注意,由于Future是運行時的effect,因此我們必須將其定義為def而不是val。因此,如果我們將其定義為val,我們將立即讀取并解析用戶的輸入。然后,當我們使用parseInt時,我們總是會獲得相同的值,而不是提示用戶輸入新值并進行解析。
拋開這一點,我們不知道通過查看類型簽名,未來會如何失敗。它可以從解析中返回NumberFormatException嗎?它可以返回IOException嗎?它會因為自己處理錯誤而完全失敗,也許是通過重試直到用戶輸入有效的整數為止?我們只是不知道,除非我們深入研究代碼并進行深入研究。
這對于調用此方法的開發人員來說更加困難,因為他們不知道會發生哪種類型的錯誤,因此為了安全起見,他們需要進行“防御性編程”并處理所有可能的Throwable。
當我們處理Future的所有可能的失敗方案時,此問題尤其令人討厭。
例如,我們可以使用Future方法fallbackTo處理parseInt錯誤:
這里parseIntOrZero不會失敗,因為如果parseInt失敗,我們將其替換為成功結果0。但是類型簽名并沒有告訴我們。 就類型簽名而言,此方法可能會無限多種方式失敗,就像parseInt!一樣!
從編譯器的角度來看,fallBackTo并沒有改變Future的易錯性。 相反,在ZIO中,parseInt將具有IO [NumberFormatException,Int]類型,而parseIntOrZero將具有UIO [Int]類型,從而精確地指示parseInt如何失敗以及parseIntOrZero無法失敗。
2.6.3 Future 沒有辦法來對 effect 的依賴關系來建模
到目前為止,我們看到的ZIO和Future之間的最終區別是Future沒有任何方法可以對effect的依賴性進行建模。 這需要其他解決方案來進行依賴注入,這些解決方案通常是手動的(無法推斷),或者依賴于第三方庫。
在本書的后面,我們將花更多的時間在此上,但是現在僅需注意ZIO直接支持依賴項注入,而Future沒有。 這意味著在實踐中,現實世界中的大多數Future代碼并不是可測試的,因為它需要太多的管道和樣板。
總結
以上是生活随笔為你收集整理的2.6 zio入门——对比Future的全部內容,希望文章能夠幫你解決所遇到的問題。