Sometimes, in the heat of the moment, it’s forgivable to cause a runtime exception.

Runtime errors suck. But when you’re working in JS they’re difficult to avoid. Fortunately though, our whole deal is problem solving; so avoid them we do.
For client-side JS this seems totally necessary: We shouldn’t subject users to runtime exceptions; we should be giving them appropriate feedback in the event of an error.
But do we always want to avoid runtime exceptions at all costs? You might have guessed that I’m not convinced we do.
In a (or at least my) perfect world, we’d have an equivalent to Elm’s compiler in every language. But in the real world, we might benefit from considering how we can save ourselves some time when things actually do go wrong.
Take this, as an example:
import someModule from ‘someModule’;

const {
someObject: {
someFunction,
} = {},
} = someModule;

Let’s assume that our code is being transpiled with Babel before it’s deployed. In this instance, if someObject didn’t exist in someModule, then this would transpile fine due to the safeguards we’ve put in place for nested destructuring. Since someModule is an external dependency, we’d be mocking it in our tests; so they would pass too. But at runtime, someFunction would be undefined.
Uncaught TypeError: someFunction is not a function.

It seems like this code is destined to fail, and unfortunately it’s going to do so for one of our users.
Consider if we’d done it this way instead, without the default value in our destructuring:
import someModule from ‘someModule’;

const {
someObject: {
someFunction,
},
} = someModule;

Now, if someObject doesn’t exist in someModule (i.e. if the package has been changed such that it’s deleted, or if someObject was added into that package in a later version than we’ve imported, or if we’ve just got the name wrong in the first place; we’re only human), we’ll get a runtime error when trying to transpile instead of after it’s been deployed.
Uncaught TypeError: Cannot destructure property `someFunction` of ‘undefined’ or ‘null’.

Not only is this feedback much faster, but it’s also going to fail on our machine. As an added bonus, this particular example can only even happen in one place in any given file (thus improving our ability to locate the problem quickly), and if we have any sort of automated build pipeline then this error now can’t even possibly make it to production; something we couldn’t say previously. Not bad considering that all we did was remove three characters.
Obviously this example isn’t indicative of every possible problem we can encounter in JS, but this was a real example that I saw recently, and was the direct result of an over-zealous approach to preventing runtime exceptions – something that the original code demonstrably didn’t even do.
TL;DR: I believe that we ought to spend a lot more time thinking about how and where our code can fail, and I think we should be very careful to consider what the unintended consequences could be whenever we’re aiming to protect ourselves from errors.

Link: https://dev.to//nimmo/sometimes-in-the-heat-of-the-moment-its-forgivable-to-cause-a-runtime-exception-2ko2