Elevator Pitch
If you depend on an external API or microservice, you can’t predict the errors your app will encounter. We’ll discuss the difficulties of running an app in an uncertain environment, and how we used Ruby’s exception handling to raise, track, and make actionable errors from external sources.
Description
When errors occur in a Ruby on Rails app, the standard practice is for a Ruby exception to be raised and cause the Rails app to return a 500 (Internal Server Error). This makes sense to keep sensitive data from being displayed to the end-user, but only if the error message is something they can’t fix. What about when end-user can get valuable information from the exception?
Our product depends on external APIs with whom we have no contract or guarantee. The behavior of calls can change over time. In this uncertain world, we needed to find a way to safely and efficiently return error messages from external services to end-users. One of our developers pointed out that using Exceptions was essentially like using a “GOTO” statement, anathema to most engineers. We’ll address the architecture of our ErrorHandler class, how we use it to display actionable error messages to end-users, and why it’s alright to use this “GOTO”-like behavior in this situation.
Our goal was to make sure that all external errors we knew about were actionable by end-users, and all external errors we didn’t know about would be sent to our error monitoring/ APM software. If your app is in a similar situation to ours - not knowing the whole data picture, dependencies on external APIs or datasources, and errors that end users can take action on, join us to learn about our ErrorHandler class.