Michael J. Ryan
1 min readApr 25, 2019

--

While I agree with the sentiment… I’d add a couple things.

First, you should have a global error trap (for client side apps/spas) that blows up the world, logs to the console and replaces the entire body content with a generic error. This ensures you are properly capturing errors. This should include the same error trap inside your main react component. By doing this, you can then prioritize trapping expected error conditions to avoid the fallback, while always having a fallback. Too many applications blindly swallow, or worse don’t handle uncaught errors (promises, react render, global error handler). If this is a Node application, also stop the world, log, wait a full minute then restart.

Second: always have a *UNIQUE* code for each location in code where you may raise an error condition for your own errors. This allows you to track down where it was raised quickly… If you are bubbling up…

catch(error) {
// catch and ensure a unique code is attached for
// finding where errors are coming from.
throw Object.assign(error, {code: error.code || ‘UNIQUEID’ });
}

You can even use a function to handle this so you can just use rethrow(error, ‘UNIQUEID` … even further, you can create a “trap(fn)” and “asyncTrap(fn)” that can wrap your inner functions in order to add the handling in a generic way.

function rethrow(error, uniqueID) {
throw Object.assign(error, {code: error.code || ‘UNIQUEID’ });
}

Yes, you should absolutely display better error messages to the user… however, too many application projects I’ve come into don’t even get the basics down right first.

--

--

Michael J. Ryan
Michael J. Ryan

Written by Michael J. Ryan

Food nerd (keto, omad, carnivore) — Programmer and JavaScript junkie! (node.js, mongodb, browser)

No responses yet