Is returning Either/Option/Try/Or considered a viable / idiomatic approach when function has preconditions for arguments?

user_3737616 0
Viewed 317

First of all, I'm very new to Scala and don't have any experience writing production code with it, so I lack understanding of what is considered a good/best practice among community. I stumbled upon these resources:

  1. https://github.com/alexandru/scala-best-practices
  2. https://nrinaudo.github.io/scala-best-practices/

It is mentioned there that throwing exceptions is not very good practice, which made me think what would be a good way to define preconditions for function then, because

A function that throws is a bit of a lie: its type implies it’s total function when it’s not.

After a bit of research, it seems that using Option/Either/Try/Or(scalactic) is a better approach, since you can use something like T Or IllegalArgumentException as return type to clearly indicate that function is actually partial, using exception as a way to store message that can be wrapped in other exceptions.

However lacking Scala experience I don't quite understand if this is actually viable approach for a real project or using Predef.require is a way to go. I would appreciate if someone explained how things are usually done in Scala community and why.

I've also seen Functional assertion in Scala, but while the idea itself looks interesting, I think PartialFunction is not very suitable for the purpose as it is, because often more than one argument is passed and tuples look like a hack in this case.

error-handling scala
3 Answers

Option or Either is definitely the way to go for functional programming.

With Option it is important to document why None might be returned.

With Either, the left side is the unsuccessful value (the "error"), while the right side is the successful value. The left side does not necessarily have to be an Exception (or a subtype of it), it can be a simple error message String (type aliases are your friend here) or a custom data type that is suitable for you application.

As an example, I usually use the following pattern when error handling with Either:

// Somewhere in a package.scala
type Error = String // Or choose something more advanced
type EitherE[T] = Either[Error, T]

// Somewhere in the program
def fooMaybe(...): EitherE[Foo] = ...

Try should only be used for wrapping unsafe (most of the time, plain Java) code, giving you the ability to pattern-match on the result:

Try(fooDangerous()) match {
   case Success(value) => ...
   case Failure(value) => ...
}

But I would suggest only using Try locally and then go with the above mentioned data types from there.

Some advanced datatypes like cats.effect.IO or monix.reactive.Observable contain error handling natively.

I would also suggest looking into cats.data.EitherT for typeclass-based error handling. Read the documentation, it's definitely worth it.

As a sidenote, for everyone coming from Java, Scala treats all Exceptions as Java treats RuntimeExceptions. That means, even when an unsafe piece of code from one of your dependencies throws a (checked) IOException, Scala will never require you to catch or otherwise handle the exception. So as a rule of thumb, when using Java - dependencies, almost always wrap them in a Try (or an IO if they execute side effects or block the thread).

user_70376950

I think your reasoning is correct. If you have a simple total (opposite of partial) function with arguments that can have invalid types then the most common and simple solution is to return some optional result like Option, etc.

It's usually not advisable to throw exceptions as they break FP laws. You can use any library that can return a more advanced type than Option like Scalaz Validation if you need to compose results in ways that are awkward with Option.

Another two alternatives I could offer is to use:

  1. Type constrained arguments that enforce preconditions. Example: val i: Int Refined Positive = 5 based on https://github.com/fthomas/refined. You can also write your own types which wrap primitive types and assert some properties. The problem here is if you have arguments that have multiple interdependent valid values which are mutually exclusive per argument. For instance x > 1 and y < 1 or x < 1 and y > 1. In such case you can return an optional value instead of using this approach.
  2. Partial functions, which in the essence resemble optional return types: case i: Int if i > 0 => .... Docs: https://www.scala-lang.org/api/2.12.1/scala/PartialFunction.html.

For example: PF's def lift: (A) ⇒ Option[B] converts PF to your regular function.

Turns this partial function into a plain function returning an Option result.

Which is similar to returning an option. The problem with partial functions that they are a bit awkward to use and not fully FP friendly.

I think Predef.require belongs to very rare cases where you don't want to allow any invalid data to be constructed and is more of a stop-everything-if-this-happens kind of measure. Example would be that you get arguments you never supposed to get.

user_12729500

You use the return type of the function to indicate the type of the result.
If you want to describe a function that can fail for whatever reason, of the types you mentioned you would probably return Try or Either: I am going to "try" to give your a result, or I am going to return "either" a success or an failure.
Now you can specify a custom exception 

case class ConditionException(message: String) extends RuntimeException(message)

that you would return if your condition is not satisfied, e.g

import scala.util._
def myfunction(a: String, minLength: Int): Try[String] = {
  if(a.size < minLength) {
    Failure(ConditionException(s"string $a is too short")
  } else {
    Success(a)
  }
}

and with Either you would get

import scala.util._
def myfunction(a: String, minLength: Int): Either[ConditionException,String] = {
  if(a.size < minLength) {
    Left(ConditionException(s"string $a is too short")
  } else {
    Right(a)
  }
}

Not that the Either solution clearly indicates the error your function might return

user_25478010
Related