some smart hack. And like every hack a two-edged sword.
Instead of writing, def fn() = { val result = someExpression doSomethingElse() result } I've found myself writing code like, def fn() = try someExpression finally doSomethingElse() more, even when `someExpression` is pure. I'm not entirely sure how I feel about it.
-
-
-
problem is the doSomethingElse is not pure.
- Show replies
New conversation -
-
-
On Scala 2.13 you could use tap: import scala.util.chaining._ def fn() = someExpression.tap(_ => doSomethingElse())
-
And `tap` is even better because `doSomethingElse()` can actually use the result value (e.g. by logging it)!
- Show replies
New conversation -
-
-
Clearly this is muuuuch better someExpression() :Id[X] <* doSomethingElse():Id[Y] On a slightly more serious note, I agree I'm not sure which is better but seing `try` immediatly get's my brain into "potentially failing" mode which might be misleading.
-
Yes, that was my feeling too. But thinking about it some more, I thought "but what if I'm wrong about it being pure?" and more often than not I concluded that my problems would be worse if an exception were thrown *and then* `doSomethingElse()` didn't happen.
- Show replies
New conversation -
-
-
someExpression <* doSomethingElse, shurely?
-
I don't have the luxury of such magic!
End of conversation
New conversation -
-
-
Try-finally triggers "resource handling" in my brain. Used this way is highly confusing to me. Also, if doSomethingElse() depends on someExpression it should be explicit imho...
-
I'd say it's a bit unintuitive, yes, based on the typical meaning of try/finally, but that's what made it interesting! Though is the use case actually so different from resource handling, if the key point is that a side-effect should always happen right after some code returns?
- Show replies
New conversation -
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.