Introduction: Understanding Error Handling in Cats with Either and Validated
Error handling is an integral part of building robust and reliable applications. Cats, a powerful library in the Scala ecosystem, offers versatile tools for managing errors functionally. Two commonly used constructs for error management in Cats are Either and Validated.
1. Either - Binary Error Handling:
Either is a straightforward construct that embodies a binary outcome - it can hold either a Left (representing a failure or error) or a Right (representing a successful result). It's a fundamental choice for managing computations with only two possible results: success or failure. However, Either operates on a "fail fast" principle, halting at the first encountered error.
2. Validated - Accumulating Errors:
On the other hand, Validated is tailored explicitly for scenarios where error accumulation is crucial. It can collect and accumulate multiple errors using its Invalid case, enabling the validation of complex data where multiple failure points might exist. Unlike Either, Validated doesn’t terminate at the first error encountered, making it ideal for aggregating validation results across multiple fields or conditions.
Exploring the Differences through Sample Applications:
In this blog, we'll delve into two sample applications, each highlighting the functionality and distinctive behavior of Either and Validated. By demonstrating practical use cases and scenarios, we aim to illustrate how these constructs differ in their approach to error handling and how they cater to various error management requirements.
Validated- E-commerce User Validation
To explain to you how Validated can be used to perform error handling we will design a user authentication system for an e-commerce application. A User when registering for an application has to go through certain steps, he or she has to give certain credentials such as First name, last name, E-mail address, etc. There are times when we have seen that there are certain constraints as to creating a username or a password, such as the password should have a capital letter, a number, a special character, etc. Error handling in a form involves checking various fields altogether and accumulating errors altogether. This is where we use Validated.
Validated is a type class in CATS that helps us accumulate errors altogether. In the application we start by creating a sealed trait which only has one singular method called errorMessage to verify the credentials we create a new method. The API is called by the application once the user submits his/hers credentials.
In this code we have seen how we can use Validated to validate the credentials of the user that he/she has put in the form. Why we cannot use Either here will become much more clear from the next example of our small API, and later we will look at why we should not interchange the two.
Functional API-Either
Either is also a type class in CATS Library which is used for error handling, although with either there is a difference in how it handles error with respect to how Validated performs error handling. As we have seen from the above Validated does not stop the operation when faced with the error it keeps on going and accumulating errors, this is essential for user experience and is line with keeping the application Available all the time.
With respect to Either, in this application we make a simple REST API which as we all know works on the principle of request-response HTTP, hence here if the request or the response action fails the operation cannot go further hence we cannot accumulate errors here.
In this application we use two case classes called Request and response and define objects such as response layer, service layer for processing the request and a response on successful receiving the request, you may or may not use a service layer.
For response status we have defined our own response status.
We have taken a very simple architecture here it is just one request and one response usually a service might be getting various requests from various other fields, we can instead of tightly couple request-response architecture also use Futures and asynchronous means to handle request and responses as well.
Conclusion-Why we should not Interchange the two in the above use cases
We should not really use validated in our API functionality as there are not a lot of criteria for errors and only one single metric to judge whether there is a fault or not. Similarly using Either in the user authentication part will stop the program for checking other conditions.
If you feel confused think of using either where you will have only one if condition, but if there are more than or multiple if conditions in the application we are checking for more conditions, hence you should use Validated.
Either will always represent a binary outcome hence only one if condition but with Validated you need to check for multiple conditions altogether.
In case of any queries feel free to contact us at hello@fusionpact.com