Should all/most methods in interfaces return Option?

Question

Is it a good practice to make all interface (trait) methods for which there may exist a future implementation with invalid arguments returning an option?

Let me give an example. If I would implement a library for probability distributions with a trait

trait Similarity {
   def getDensity(): Double
}

Since most distributions are not defined over the whole real space, there are always some illegal parameters e.g. a non-positive variance for a Gaussian distribution. If I understood it correctly, I should return an Option[Double] rather than a Double and throwing an IllegalArgumentException.

I think the same is true for most functions/calculations. What is "best practice" in this case? I am afraid this would make a library overly clumsy.

Thanks

Answer 1

I wouldn't throw an IllegalArgumentException as it is not the arguments that are the problem, but the state of the object. If it were to be an exception, IllegalStateException would match.

However, the real answer depends on what you expect the caller to do in the case of a problem.

If they would themselves throw an exception, that's what you should do, saving them the bother.

If they would do something different based on the answer being impossible, an Option[Double] is a good indicator.

A possibility worth knowing of, but less likely to be useful, is Double.NaN, effectively a Null Object but for Doubles.

Answer 2

The answer is mostly a question of style and intent.

There's actually nothing wrong with throwing an exception if the error is actually an exceptional condition. If you decide to go down the path of throwing an exception, I would recommend throwing an ArithmeticException, or some subclass of it that you write, since that's more indicative of what the problem is.

Is this the sort of error that could happen frequently, and is best handled by the caller? Or is this more of a rare situation that's best handled at an upper layer? Or maybe even an indicator of some more fundamental error, such as a data or coding problem?

For comparison, it's true that dividing an integer by 0 is invalid, but forcing everyone to deal with that every time they divide would get old quickly. This is especially true when you know for certain that the exception will not be thrown with the data you're giving it. Imagine writing x / 2 + 5:

// normally
x / 2 + 5

// divide returns Option[Int]
(x / 2).map(_ + 5).get

// divide returns Either[ArithmeticException, Int]
(x / 2).right.map(_ + 5).right.get

If this error is something the caller can and should handle, then Option[Double] or Either[someErrorClass, Double] would be good.

Option is nice if you don't care why it failed/is invalid, just that it is. It's also fairly easy for the caller to deal with.

Either is good if there are multiple reasons why it would fail, and it's important for the caller to know why. This can be slightly more difficult to deal with than Option, though.