Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Your app blows up in production. It's an outage and you're under pressure. You read the code. "How does this work? Why is this exception being caught here?" And so begins a long, stressful journey to understand how to fix your code. Rescuing exceptions is normalised in Ruby, but it's a clumsy way of reacting to error conditions and causes your code to be difficult to reason about. You'll refactor an existing app to use a functional style and see first hand how easy monads are to use and how they can make your code incredibly clean and expressive.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the presentation titled "Using Monads for Elegant Error Handling" at RubyConf 2021, John Gallagher discusses the challenges of managing exceptions in Ruby applications and how adopting a functional approach using monads can streamline error handling. Gallagher highlights several key issues with the traditional method of handling exceptions in Ruby: - **Difficulty in understanding code**: When an application fails, developers often find it hard to trace the source of the error due to scattered exception handling. - **Clumsy exception rescue**: Normalizing exception rescue makes the code difficult to reason about, leading to potential bugs and maintenance issues. - **Coupling between methods and error handling**: Developers may inadvertently confuse different failure modes due to returning nil or empty arrays, which can lead to faulty logic in the client code. To illustrate these issues, he provides an example involving a customer address-editing process that requires multiple API calls. In the traditional approach: - API failures lead to returning nil for a failed request, or an empty array for no results, making it unclear what went wrong. - This can cause confusion in the controller that processes results, increasing cognitive load and reducing code clarity. Gallagher introduces the concept of the **Result Monad** as a solution to these problems. He emphasizes that the Result Monad can encapsulate both success and failure states, providing a consistent interface for error handling. The benefits of using Result Monads include: - **Improved clarity and reasoning**: With a clear distinction between success and failure encapsulated in distinct objects, developers can handle errors in a more structured way. - **Pipelines for composing operations**: Gallagher explains how monads allow for cleaner, more readable pipelines that can handle series of operations without deeply nested if-else structures. He demonstrates how to refactor existing code to utilize dry-monads, highlighting the following points: - The new system allows chaining operations with `fmap` for successes and `or` for handling failures. - The controller code is simplified by eliminating the need for multiple checks and allowing for straightforward error handling in a linear flow. - Errors can be preserved for logging or further action, unlike the conventional method where exceptions might be lost. In conclusion, Gallagher encourages developers to consider adopting monads as they can make error handling more elegant and manageable. However, he warns that such a transition involves further learning and could increase boilerplate code and dependencies. Ultimately, monads enhance readability, scalability, and maintainability of Ruby applications, making them a fitting choice for error handling in complex systems.
Suggest modifications
Cancel
