I was reading this StackOverflow answer about the distinction between methods and functions. It had the usual explanations, for example a method "can be easily converted into [a function]" but "one can't convert the other way around"; methods "can receive type parameters"; "a function is an object" etc.
But as pointed out here, return behaves differently in a function compared to a method and can be used to short-circuit a fold etc.
For example:
def caller(): Any = {
println("caller started")
val g = () => { return true } // note: return type must be compatible with this method
called(g)
println("caller finished") // this is never executed!
}
def called(innocuousFn: () => Boolean): Unit = {
println("called: about to call innocuousFn...")
innocuousFn()
println("called: finished") // this is never executed!
}
prints out:
caller started
called: about to call innocuousFn...
That is, when the flow of control hits the function's return statement, the execution stack is popped as if it were in the enclosing method (it's illegal for a function outside a method to have a return statement).
Worse, if one method passes a returning function back to the method that calls it, you get a Throwable. After all, where does that function return from?
def executeReturningFnFromOtherMethod(): Unit = {
println("about to call calledReturnsFnThatReturns")
val fn: () => Boolean = returnsFnThatReturns()
println("about to call fn")
fn() // Exception in thread "main" scala.runtime.NonLocalReturnControl
println("finished") // never executes
}
def returnsFnThatReturns(): () => Boolean = {
val fn: () => Boolean = () => {
return makeTrue
}
fn
}
def makeTrue(): Boolean = {
return true
}
Prints out:
about to call calledReturnsFnThatReturns
about to call fn
Exception in thread "main" scala.runtime.NonLocalReturnControl
No comments:
Post a Comment