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