@dibblego @mergeconflict which is the intent of try. Don't use it if you want your arrows catching exceptions.
-
-
Replying to @jsuereth
@jsuereth@mergeconflict I think more accurate is, "don't use it if you want your program to work."1 reply 0 retweets 0 likes -
Replying to @dibblego
@dibblego@mergeconflict to be fair, I feel that way about exceptions. Would rather see types encode possible failures.2 replies 0 retweets 0 likes -
Replying to @jsuereth
@jsuereth@mergeconflict Sorry, but scala.util.Try is a total write-off and should never be used in my opinion.1 reply 0 retweets 0 likes -
Replying to @dibblego
@dibblego@mergeconflict isn't that your opinion of scala now, too?1 reply 0 retweets 0 likes -
Replying to @jsuereth
@jsuereth@mergeconflict No, not sure why you think that. The current implementation of Try is has no redeeming qualities.1 reply 0 retweets 1 like -
Replying to @dibblego
@dibblego@mergeconflict well, scala blends inheritance + FP. Doesn't seem your first choice of design goals.4 replies 0 retweets 0 likes -
Replying to @jsuereth
@jsuereth@mergeconflict ...they usually have some redeeming, even if degenerate, quality. That cannot be said for this latest case study.3 replies 0 retweets 0 likes -
Replying to @dibblego
@dibblego@mergeconflict Which is a general issue with CT and Scala's A => B types. You can't enforce a categorical limit A => B well.1 reply 0 retweets 0 likes
@jsuereth @mergeconflict I have no idea how that redeems Try from being a write-off. There is no use-case for it.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.