Error handling can be a confusing topic — for a long time I struggled to understand error handling myself. I found the whole topic quite mystical and daunting. I ended up subscribed to the school of thought: “let the error throw and pray”. But, over time, I learned there are simple, easy to understand strategies for error handling that lead to noticeably better results than hope alone!

If, like I did, you also have difficulty understanding error handling then you’re in the right place. After years working with JavaScript, and speaking/working with other engineers, a style of applications layout for handling errors emerged in my own work. And it’s this philosophy for error handling that I want to share with you today.

By the end of the article you’ll understand how to structure an application to handle errors effectively, achieve more understanding of the application, deliver better error messages and have an easier time debugging.

I’ve spent the last few days wrangling with Yarn errors. Our builds we’re failing in some weird and random ways — and all signs pointed at Yarn. I can give you the TL;DR; of the investigation, and it’s this: Yarn doesn’t handle upstream NPM infrastructure errors in ideal ways.

But the problem is not that Yarn code is buggy — the problem is in the disconnect which exists between Yarn (the client) and NPM’s infrastructure. The errors caused are significant enough to start conversations for moving to the NPM client. But moving back to NPM raises a bigger question about the viability of third-party package managers that rely on NPM infrastructure.