0

I've been reading up on how to properly handle (Option, Try and Either) and define exceptions in Scala.

My question is: do exception hierarchies make sense in Scala? For example, we currently have a Scala project implementing something like:

class ServiceException(msg: String) extends Exception(msg)
class StorageServiceException(msg: String) extends ServiceException(msg)
class StorageServiceNotAvailableException(msg: String)
  extends StorageServiceException(msg)

Is there an idiomatic way of defining such a hierarchy? Or maybe this concept is absorbed into something different altogether?

CONCLUSION FROM RESPONSES (see answer and comments below)

A hierarchy of exceptions makes sense if you want to recover from a non-leaf exception. Although, this doesn't prevent you from handling with Option/Try/Either mechanisms which is more idiomatic than the traditional try/catch.

Daniel Severo
  • 1,768
  • 2
  • 15
  • 22

1 Answers1

4

First of all answering your question, the current implementation of exception hierarchy is the idiomatic way of declaring the hierarchy. This implementation is basically inherited from java style of coding. You map also refer to https://stackoverflow.com/a/10925402/7803797 for more details.

In my opinion, using such exceptions is a bad idea in Scala. Scala provides a beautiful construct called the Either type that allows you to handle exceptions gracefully. Please go through https://dzone.com/articles/catching-exceptions-in-scala-part-2 to understand this clearly.

Now explaining it in much more detail ...

Basically, in functional programming, composition is a key aspect. Now when you try to throw exceptions, you abruptly come out of the stack frame and the control of the code is delegated to the caller. Having a construct such as Left of type Either comes in handy here as it does not break composition. You are still in the same stack frame and exit from the method gracefully.

I hope this answers your question.

Chaitanya
  • 3,590
  • 14
  • 33
  • Thanks for answering! Good reference, but from what I understand it relates to how I handle and detect the exceptions, not how I define them. Correct? For example, on line 13 it matches for an ArithmeticException. My question relates to the construction of new exception types. Or are you suggestion I stick only to native Scala exceptions? – Daniel Severo Mar 25 '19 at 19:06
  • 2
    There is nothing wrong in defining an hierarchy of exceptions and use them as the **Left** _type_ of your `Either`. The real question is, if that gives you value. If you are going to only print/log them why simply do not have plain `String`. However, if you perform custom actions for each specific error, then yes having them as case classes makes sense. – Luis Miguel Mejía Suárez Mar 25 '19 at 19:32
  • 1
    I agree with @Luis, there's nothing wrong with an exception hierarchy if that's how they'll be interpreted, i.e. if sometimes you want to handle _all_ `ServiceException`s, regardless of sub-type, and sometimes you want to segregate the exception types. – jwvh Mar 25 '19 at 19:57
  • I've updated the original question to reflect my conclusions. Hope I got the gist correctly. Thanks everyone! – Daniel Severo Mar 26 '19 at 15:01