00:00:14.309
Let's talk about it! I definitely recognize some faces in the audience, but for those of you that I don’t know, my name is Brittany. I am an instructor and tech lead at Turing School. If I don't have a chance to meet you before the end of the conference, you can find me on GitHub at Brittany Storoz, on Twitter, or pretty much anywhere on the Internet.
00:00:40.090
Okay, so today I want to talk about the nightmare that is error handling and error messages, and what we can learn from the pretty minor mistakes that we make, and the terrible error messages that we receive in return. This talk is mostly going to be me complaining at you, but I'm going to assume that as developers, we're all cool with that.
00:01:06.189
Since I've been teaching, I’ve had a lot of students coming from very different backgrounds with varied skill sets. As they progress through the program, certain students excel in specific areas of programming while struggling in others, and vice versa. Over the past couple of months, I’ve noticed a handful of common and pervasive technical hurdles that significantly affect the learning process for students.
00:01:42.729
A lot of times, new developers have trouble wrapping their heads around concepts like abstraction and modularity; sometimes things seem like a big black box of magic. The sheer size and number of files in a particular project can be overwhelming, and the myriad of tools, frameworks, and libraries we work with makes decision-making incredibly challenging. How do I know if I’m picking the right toolset for the application that I’m building? We've always had issues with writing good documentation, so when people try to reference the docs, sometimes they're just not available.
00:02:26.240
There are various technical hurdles for new developers in programming, but today I want to specifically focus on error handling. Earlier this week, I was speaking on a panel at Denver Startup Week about navigating the path from being a junior developer to a senior developer. One of the key themes that emerged from that conversation was that the journey to becoming a senior developer is filled with accumulating failures.
00:02:39.410
You're just making mistakes constantly and committing them to memory. You will keep making several mistakes, but you will remember what they were, how frustrated you were, and how long you spent debugging them. Then, when you encounter them again in the future, you'll be able to fix them much more quickly, and when you see other people struggling with them, you'll be able to offer help as well.
00:03:11.180
So what actually happens when we fail, when we make mistakes in our code and run into bugs? Often, we receive these obscure, confusing error messages that are sometimes really unhelpful and often indecipherable. In these cases, failure may not be an option, but we are presented with options that are often intimidating and nonsensical. These messages can be visually offensive, and frankly, catastrophic.
00:03:42.640
These are the types of error messages we're giving people when they make a mistake or do something trivially wrong in their programming. I have to say that this is our fault as developers. We truly can't blame anyone else for this; it is our doing, and I think it’s our responsibility to fix these issues. So take a moment to come to terms with the fact that we’re not doing great.
00:04:36.289
I have one admission to make. I'm going to preface the rest of this talk with an apology and a plea not to hate me because I am actually a JavaScript developer, not a Ruby developer. I don’t know much about all the Rubies, gems, and Rails that you are using, but that makes me a perfect person to talk about error handling.
00:05:19.969
Since I’ve been teaching, I have been working with the front-end program at Turing, where I’ve seen all the errors that my students encounter when building the front end of their applications. As a senior engineer, I lost perspective on how difficult it is to parse certain error messages and call stacks presented to new developers when they make mistakes in their codebases. Specific messages that are simple for me to understand were completely mysterious to my students, and that is not their fault—it’s our fault that the system behaves this way.
00:06:18.110
For example, we use React at Turing School. There’s an error message that you might see which simply states there’s an uncaught error indicating that a specific module can’t be found. But when you look in your codebase, you might clearly see that module; you wrote it, you imported it. So why can’t your program find it? It’s actually because there’s a syntax error somewhere within that module, preventing it from loading.
00:06:56.729
How is a new developer supposed to understand that? How are they supposed to recognize that this message does not accurately reflect what went wrong? About a year or so ago, I encountered a really scary error related to a fetch request to an API endpoint for JSON data. I was doing something with the response body and then trying to reuse it, but I still have no idea what I did wrong to make it behave that way. It was creepy.
00:07:55.770
One of the more recent issues highlighted this very topic. One of my students faced a problem while deploying their first full-stack application to Heroku, which was incredibly exciting. I told them, 'Well, we taught you how to look at the error logs in Heroku. How do you inspect them?' I sent my student to check the error logs, and the terminal output simply stated, 'We need a better error message.'
00:09:02.240
I felt personally embarrassed by this. Although I had nothing to do with the libraries we were using or the tech stack—and I did not write that error message—I was embarrassed that we have been tolerating such poor standards as an industry and culture. I had sent one of my students to analyze logs I assumed would be reliable, only to find out they were completely useless.
00:09:54.290
This experience sparked my desire to think critically about the error-handling culture in JavaScript as a whole and why it seems broken. I entered this talk with the hypothesis that other languages might not tolerate such poor error messaging. I figured I would test this by building an application with Ruby on Rails.
00:10:59.560
In the past, I had struggled with Rails due to applications running on different versions—some on Rails 2 and some on Rails 3—and it was a challenge for me as a younger developer. Now, with more experience, I thought I would see if I could better parse the errors in a Rails application.
00:11:50.090
The very first error I encountered was related to installing MySQL with a message indicating a failure to build a gem native extension. This is a common error, and it took me a couple of hours to navigate through the various solutions available. Luckily, a Stack Overflow post had around 50 solutions for me to try. Eventually, I got through it and started building my tutorial application.
00:12:38.510
I repeatedly ran into another error stating 'No method error in Posts controller: Undefined method posts for nil nil class.' This error reminded me of a notorious JavaScript error—'undefined is not a function.' In both cases, the key part of the error message becomes elusive, making it hard for developers to identify what went wrong.
00:13:10.000
As a junior developer, figuring out how to Google errors is quite challenging. For instance, when I see an error message referencing 'posts,' I immediately relate it to something I wrote, believing it indicates a fault within my code specifically. When I search for that, the results are unlikely to yield relevant responses because many applications do not have a 'posts' feature.
00:14:50.660
The last error I stumbled upon was a 'No implicit conversion of string into integer.' In JavaScript, being dynamically typed can sometimes mask such problems, and typically, we don't receive explicit errors until we encounter unexpected behavior. I remember encountering this issue when I was using bracket notation to grab an item from an array with a string instead of an integer as the index, leading to the failure.
00:15:48.360
Through my experience, I’ve come to recognize that error handling is predictably bad, and I've identified common themes and limitations that hinder its effectiveness. One of the primary reasons error handling is poor is that errors are often written for developers rather than the actual users of the application.
00:16:54.360
When I refer to users, I mean both typical web users and developers who are utilizing a new library or framework. These developers might be using your application as their toolset for the first time; they don’t hold the advanced knowledge of an application’s specifics. Unfortunately, as maintainers of open-source applications or language specifications, we sometimes lose sight of this.
00:17:40.900
The complexity of evolving codebases often leads to more convoluted error messages, making it seem as though everyone using your work has the same background, when in fact, they do not. These newcomers are essentially 'juniors' in those environments regardless of their prior experience, and it’s crucial for us to craft error messages that acknowledge this.
00:18:58.390
Another issue is that programs can only interpret a limited understanding of developers' intent. For example, an error such as 'Syntax error: unexpected token' often has limited context that does not articulate what the developer intended. Similarly, during JSON parsing, if we unexpectedly encounter HTML instead of the anticipated JSON, the response is inadequate in helping the developer understand what really went wrong.
00:20:27.920
The final, and perhaps most significant, reason error handling is so poor is that we, as an industry, can be quite lazy. We often do not prioritize error handling during tool development, relegating it to a secondary concern once everything else is functioning. This is unfortunate because vague, cryptic error messages become a significant barrier for new developers.
00:21:18.300
A quick search on GitHub for 'better error' yielded nearly a million issues surrounding better error messages and error handling. While a number of these have been resolved, it often feels like people are prioritizing shipping their code and dealing with error handling afterward.
00:22:04.050
For example, JavaScript has over 135,000 issues labeled with 'better error handling,' in stark contrast to Ruby's 44,000. At first glance, it could imply that JavaScript is much worse regarding error messages; however, it may also indicate that we care more about improving and refining these elements.
00:22:43.760
We established earlier that error handling problems are predictable, and as developers, we tend to find and devise solutions for these predictable errors. Such problems are manageable because they present patterns we can learn from. Fixing these issues requires a few key considerations.
00:23:46.470
One consideration is using self-correcting errors and increasing awareness of intent. We already see this with tools like RuboCop, which can auto-correct linting errors, while JavaScript has similar linting tools like ESLint. This type of static code analysis is immensely beneficial for catching common issues.
00:24:24.640
I recently spoke with a developer at Google, who works on the V8 JavaScript engine. He mentioned that a goal is for the system to detect when a variable is undefined while noticing a similarly named variable used throughout the codebase. This way, if there is a typo, we might be able to help developers identify where they went wrong.
00:25:10.880
There are community resources available, such as Stack Overflow, where developers share many solutions to common bugs. One shining example of good error handling is in Chrome's Developer Tools under the audits panel. When you invoke an audit, it provides both error details and resources linking you to valuable documentation for resolution.
00:25:50.770
As developers, we often strive for brevity and conciseness in our programming practices, but error messages should be exceptions to this rule. It’s better to provide comprehensive, informative error messages that offer users potential directions to seek answers instead of leaving them to Google on their own.
00:26:45.370
One key to effective error messaging is writing for our users rather than ourselves, recognizing that regardless of experience level, everyone is a novice in new languages and libraries. This perspective was reinforced during a recent TC39 meeting where proposals were frequently evaluated in terms of their accessibility for newcomers to JavaScript.
00:28:09.270
Thus, it’s vital to prioritize our junior audience’s understanding in any programming language or framework. Ultimately, building trust with users pertains heavily to the quality of support provided by applications, especially through clear and informative error messages.