I’ve met tons of developers who would not do error handling because of fear of it being too much.
Here’s a short list of reasons:
- We’re going to write too much boilerplate because the properties are too deeply nested. The code will look ugly.
- Why write a ton of
ifstatements? The server always returns that response, why bother?
- Why validate this input — it’s declared as
type="number"in the DOM so it only takes numbers.
I know they might seem stupid but I’ve both heard and uttered such nonsense. On the flipside, I’ve changed my opinion about error handling, after I got older.
I even wrote an article and recorded a podcast episode that are tangential to the topic.
- Improve your Node.js code readability with this simple trick
- Dev Time Stories Episode 3 — Five steps to quickly track down and handle uncaught exceptions in Node.js
In the past 1.5 years I’ve been dabbling more and more into GraphQL but I’ve never brought my error handling chops up to speed. I still kept on handling errors my way.
Decided to actually learn how it’s done in this particular technology, so I’m digging through the Apollo Server documentation, yet again. Here’s a useful link if you’re curious, too.