scala.util.Tryが使いづらい？

Kenji Yoshida @xuwei_k

「scala.util.Tryが嫌いな理由」という感じでブログ書こうとして、そういえばtwitterから来たわけだし「改めてTryが使われてるコードを見なおしてから記事書こう！」と、(おそらく一番多く使われているであろう)finagleのコード見たら、複雑で理解できなくて死・・・

Kenji Yoshida @xuwei_k

scala.util.Tryについて言えるのは「失敗をThrowable型でしか持てない」のが大きな特徴で、Throwable以外のもっと扱いやすいオブジェクトにその場で変換できるならTryいらない(?)とか、じゃあThrowableってそもそも何？とか考える必要がある気がして

Kenji Yoshida @xuwei_k

思いつくのは ①例外を多く投げるようなJavaのライブラリ使う場合、Throwableを多くの場面で扱わないといけない ②StackTraceや、発生元の例外を保持する機能がある ③投げることができる(つまりもう一度投げる可能性がある？) などで(続く

Kenji Yoshida @xuwei_k

ある程度単純なもので、Javaのライブラリを多く使わないのなら、そういうのあまり必要ないよなーというのが、今のところの個人的な感覚。 なんかThrowable自体が低レベルすぎるというか、抽象化されてないというか、よってThrowableの使用を強制されるTryも微妙に使いづらい

Kenji Yoshida @xuwei_k

逆にfinagleのような、低レベルな並列処理を扱うような複雑なライブラリなら、Try必要なのかなぁーと勝手に想像したけど、finagle自体ある程度大きくて全体を把握するの大変なので、誰か「finagleの中でのTryの使われ方」とかエラーの扱い方をまとめた話を・・・(他力本願

Yuta Okamoto @okapies

@xuwei_k それなりに見て回った気がしますが、基本的に Future に wrap されてるので直接使ってるところは多くないんじゃないかなぁとは。

Kenji Yoshida @xuwei_k

@okapies 適当にいくつかのtwitterのライブラリをTryでgrepしたら、こんな感じで https://t.co/hX6jTMYNqh finagleがそれなりに多かったですね。あとTry[Nothing]型をいくつか使っていて「なんだこのテクニック・・・」というのが

Yuta Okamoto @okapies

@xuwei_k ありがとうございます。test をフィルターしてやると、そんなに多くない気もするんですよね。パッと見、リトライで何かしてるところが目立つのでご飯食べたら調べてみます。

Kenji Yoshida @xuwei_k

あと(個人的にオブジェクト指向的なポリモーフィズムが嫌いというのもあるけど) Throwable型で持たれたら、それ使うときにどういう情報保持してるのか(エラーメッセージは有用なのか、発生元の例外持ってるのか、などなど) 型からは全く判別できなくて、やっぱり不便とか

Yuta Okamoto @okapies

@xuwei_k 一通り調べてみました。まず、エラー原因を保持するために使っているもの。 https://t.co/UIUqg8CFqs https://t.co/9Y3zKSqPzo https://t.co/BBfiZOCVey

Yuta Okamoto @okapies

@xuwei_k 次に、Promise の updateIfEmpty が Try 型を要求しているので、というもの。 https://t.co/SyUdcf2FC6 try 式を短く書くために使っているもの。 https://t.co/rZuSWygmEc

Yuta Okamoto @okapies

@xuwei_k あと、RetryingFilter の Try[Nothing] の件ですが、単にリトライ条件である例外にしか関心がないから、という話のように見えます。 https://t.co/ZgwupB4ReC

Yuta Okamoto @okapies

@xuwei_k いちおう test も見てみたんですが、例外の種類を assert するのに使ってる場合もあるみたいです。 https://t.co/mqPBBeikNw

Yuta Okamoto @okapies

基本的には、例外の種類によって hogehoge したいとか、例外を呼び出し元で log させたい場合とかに使ってる、という話なのかなぁ…。

Yuta Okamoto @okapies

本当は Future の使い方を調べた方がいいのかも。Future#apply[A](a: => A) = const(Try(a)) だし。

Kenji Yoshida @xuwei_k

@okapies Futureとの関連でいえば、最近Scalazに入ったFuture https://t.co/wDyWFnE8XF が、そもそも独自実装だし、Future自体はエラー処理提供してなくて、別にTaskというものがある、という仕組みになってておもしろいんですけどね

Yuta Okamoto @okapies

@xuwei_k おー、面白そうですね。ご教示ありがとうございます。

がくぞ @gakuzzzz

なるほどなー http://t.co/wK2m4WdMVN 個人的には Scala はどうせ全ての例外が非チェック例外なのでTryで例外の型情報が落ちるのはあんまり気にならない感じ。Javaみたくチェック例外なら型情報ないと困るけど

がくぞ @gakuzzzz

Try や Future で困るのはログしこみたい時にどうすればいいのか良くわかんなくて困る。for式でさっと合成できるのはいいんだけど、その個別のFuture毎にログ出力したいんだけど、みたいな時どうすればいいのか。