Error Handling Best Practices

Error Handling Best Practices

The best overview of the error handling options in the standard library we are aware of is tersesystems.com/2012/12/27/error-handling-in-scala, by Will Sargent, a former Lightbender.

Digression: One topic he doesn’t cover is why checked exceptions have fallen out of favour. In short, given our current approaches to writing generic code, we’re unable to abstract over the types of checked exceptions. What would be the throws clause of Function1.apply, or a higher order function like Option.map? This tension is covered in some (academic) detail in http://www.cs.kuleuven.be/publicaties/rapporten/cw/CW407.pdf. Lukas Rytz (now in the Lightbend Scala team) researched “lightweight effect polymorphism” for his thesis. This made it as far as a prototyped extension for the compiler (https://github.com/lrytz/efftp/wiki/Exceptions), but is not likely to be developed further and to land in mainstream Scala.

You can actually declare exceptions in Scala with the @throws annotation, but there is no compiler enforcement of Java’s “catch or redeclare” rule. (It will force Java clients to deal with them, though.)

If you decide to introduce a data type to explicitly represent potential failures, you have to find the best fit with your use case.

  1. Stdlib error types (Try, Either)
  2. Define your own data type for representing the success and failure cases for important public APIs.
  3. Use a data type from a 3rd party library, such as scalactic.{Validation, Or} or scalaz.{Disjunction, Validation}

Those third party data types differ from the the standard Either in two ways: 1) being biased, meaning you can call map or flatMap and operate on the Success value; 2) some allow error accumulation, which can elegantly express code that has to report multiple errors in one pass, rather than failing fast on the first error. Form validation is a typical use case here.

Please note that we do not maintain the code of scalactic or scalaz and these are not covered by your support subscription. Use at your own risk.

​


    • Related Articles

    • Can Lagom errors be handled using Play error handling?

      No, the Play error handler is not invoked from Lagom, because the Lagom exception serializer intercepts it first. Any exception thrown by application code will be wrapped in a transport exception, serialized to json and a response is built from it. ...

    • Enum Best Practices

      There are different options to implement enums in Scala. The landscape is roughly: 1. scala.Enumeration Pros: Library code only. Does not create a class per enum value for simple enums without behaviour. Cons: need to use dependent types to refer to ...

    • Can I customize error handling in Lagom?

      Yes, the best way to customize error handling in Lagom is to use a custom ExceptionSerializer.  This Knoldus blog post explains it well: https://blog.knoldus.com/2018/02/05/exception-serializer-in-lagom/ That example, however, is more focused on how ...

    • Error handling and recovery in Akka Streams

      When developing applications you should assume that there will be unexpected issues. For this, Akka provides a set of supervision strategies to deal with errors within your actors. Akka streams is no different, in fact its error handling strategies ...

    • Best practices for picking number of shards for Aggregate Event Tags

      Lagom's  documentation states that you should not change the number of shards for a given AggregateEventTag that you have sharded. What is a good baseline number of shards to pick? What sort of impact does the number of shards have in terms of ...