Reporting Errors with Either | CodeSignal Learn

Reporting Errors with Either | CodeSignal Learn

Introduction: From "Nothing" to "Why"

Welcome to the fifth unit of our course! In our previous lesson, you learned how to handle missing data safely using Haskell's Maybe type. You practiced returning Nothing when a task couldn't be found and returning Just task when the search was successful. While Maybe is fantastic for handling absence, it has a limitation: it cannot tell us why an operation failed. Returning Nothing is like a package delivery status that simply says "Not Delivered." As a user, you would much rather see a status that says "Invalid Address" or "Lost in Transit," so you know exactly what went wrong. When you need to know the reason for a failure, Haskell provides a built-in type called Either . The Either type has two possible states, or constructors: Left and Right . By standard convention in Haskell, the Right constructor holds the "right" or successful answer, while the Left constructor holds the error message or reason for failure. In this lesson, we are going to upgrade our task manager to reject invalid task IDs (like negative numbers) and explain exactly why the input was rejected.

Validating Data with Either

Let's begin by writing a function that checks if a user's requested ID is valid. We will call this function validateId . First, let's look at the type signature: validateId :: TaskId -> Either String TaskId As you recall from our first unit on naming your domain, TaskId is simply a descriptive alias for an Int . Our function takes this TaskId and returns an Either type. This Either will contain a String if it fails (the error message) or a TaskId if it succeeds. Now, let's implement the logic to check if the ID is less than 1 . validateId :: TaskId -> Either String TaskId validateId tid | tid < 1 = Left "Id must be positive." Using standard Haskell guards, we check if tid is less than 1 . If it is, the ID is invalid. We return our helpful error string wrapped inside the Left constructor to signal a failure. Next, we handle the success case: validateId :: TaskId -> Either String TaskId validateId tid | tid < 1 = Left "Id must be positive." | otherwise = Right tid If the ID is 1 or greater, we fall through to the otherwise condition. Here, we wrap the valid ID in the Right constructor, safely passing it along for the next step in our program.

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Now that we can validate an ID, we need a way to process the Either result. We will write a function called lookupById . Let's start with the signature: Haskell lookupById :: [Task] -> Either String TaskId -> String This function takes our list of tasks and the Either result generated by our validateId function. It will process both and return a formatted String to show the user. To extract the data from the Either type, we will use the pattern matching skills you learned in unit three. Let's handle the Left case first: Haskell lookupById :: [Task] -> Either String TaskId -> String lookupById _ (Left err) = err If our validation function returned an error, lookupById matches the (Left err) pattern. Because we are just surfacing an error, we don't need to look through the list of tasks. We use an underscore_to ignore the task list and simply return the err string directly. Now, let's add the pattern match for a successful validation: Haskell lookupById :: [Task] -> Either String TaskId -> String lookupById _ (Left err) = err lookupById tasks (Right tid) = report (findTask tid tasks) If the ID was valid, we match the (Right tid) pattern. This extracts the safe tid integer. We then pass that valid ID to the findTask and report functions that we built in our previous lesson. This seamlessly connects our new validation logic to our existing search logic.

Wiring It Together in Main

Let's see how this all connects in practice. We will use a small list of sample tasks and call our new functions inside main . Haskell tasks :: [Task] tasks = [Task 1 "Write report" Todo, Task 2 "Review code" Done] main :: IO () main = do putStrLn (lookupById tasks (validateId 1)) In this code snippet, we first pass 1 to validateId . Because 1 is valid, it returns Right 1 . The lookupById function matches Right 1, searches our list, and formats the found task. Let's add a valid but missing ID to the mix: Haskell tasks :: [Task] tasks = [Task 1 "Write report" Todo, Task 2 "Review code" Done] main :: IO () main = do putStrLn (lookupById tasks (validateId 1)) putStrLn (lookupById tasks (validateId 9)) Here, validateId 9 returns Right 9 . It passes validation, but when lookupById searches the list, the task doesn't exist. Our older Maybe logic catches this and returns our standard "missing task" message. Finally, let's add an invalid ID to trigger our new Either error logic: Haskell tasks :: [Task] tasks = [Task 1 "Write report" Todo, Task 2 "Review code" Done] main :: IO () main = do putStrLn (lookupById tasks (validateId 1)) putStrLn (lookupById tasks (validateId 9)) putStrLn (lookupById tasks (validateId 0)) When we run this completed program, the output looks like this: text #1 Write report (not done) No task with that id. Id must be positive. For the last line, validateId 0 triggers our guard condition and returns Left "Id must be positive." . The lookupById function catches the Left pattern and prints the exact reason why the input failed. We now have a robust pipeline that handles valid searches, missing data, and bad input gracefully!