Chapter 7. Handling errors and exceptions
This chapter covers
- Holding information about errors with the Either type
- Easier error handling with the biased Result type
- Accessing the data inside a Result
- Applying effects to Result data
- Lifting functions to operate on Result
In chapter 6, you learned how to deal with optional data without having to manipulate null references by using the Option data type. As you saw, this data type is perfect for dealing with the absence of data when this isn’t the result of an error. But it’s not an efficient way to handle errors, because, although it allows you to cleanly report the absence of data, it swallows the cause of this absence. All missing data is thus treated the same way, and it’s up to the caller to try to figure out what happened, which is generally impossible.
Most of the time, the absence of data is the result of an error, either in the input data or in the computation. These are two very different cases, but they end with the same result: data is absent, and it was meant to be present.
In classical imperative programming, when a function or a method takes an object parameter, most programmers know that they should test this parameter for null. What they should do if the parameter is null is often undefined. Remember the example from listing 6.3 in chapter 6: