Now I feel the need to defend my solution of adding runtime code to ensure that a critical npm package is working as expected. I'm sure there are lots of developers out there that think that this kind of check is not needed, but what I like to remind people is that a system can fail for any number of reasons (CPUs can make mistakes or a bit can be flipped in memory due to an electrical surge). I usually don't work on software where people's lives depends on it, but I like to code as though I do. And for that, defensive programming is key. Not only do I add runtime checks in all of my functions to detect runtime bugs, I also like to add code that will look back at the call trace and fix the problematic code by patching code using heuristics and sophisticated algorithms to prevent problems from spreading to other parts of the system. I've been coding for years and this strategy has served me well.
Now I feel the need to defend my solution of adding runtime code to ensure that a critical npm package is working as expected. I'm sure there are lots of developers out there that think that this kind of check is not needed, but what I like to remind people is that a system can fail for any number of reasons (CPUs can make mistakes or a bit can be flipped in memory due to an electrical surge). I usually don't work on software where people's lives depends on it, but I like to code as though I do. And for that, defensive programming is key. Not only do I add runtime checks in all of my functions to detect runtime bugs, I also like to add code that will look back at the call trace and fix the problematic code by patching code using heuristics and sophisticated algorithms to prevent problems from spreading to other parts of the system. I've been coding for years and this strategy has served me well.
Ah I see. Defensive programming is indeed the future.