The arguments of this article are ridiculously bad in my opinion.
Defensive programming does not mean that you ignore errors.
It means that the dev should always expect the worse and decide right away how to deal with it early.
Imagine you have a car that suddenly block and explode each time an unexpected error is encountered. So that you are sure to catch it.
So, you are driving on the highway, then a there a window fuse that blow and because of that your car decide to brake and explode...
Especially in hardware and embedded, you have to expect the unexpected to happen.
Imagine the car will suddenly stop when a lightbulb break or there is a shortcut in windows control. Sure you will know, but you will have 300 000 cars all around the world bricked!
Author here! I don't think we are in disagreement, just mostly in different interpretations. You are talking about a car, with likely 200-300 embedded systems backed into it.
If the light sensor or the braking module goes into a completely unexpected state where it can no longer be communicated with, it has corruption, etc, you need to do something about it.
The solution isn't to reboot the car, it's to reboot the individual module and quickly get it back into working order. Rebooting the braking or lighting module should take on the order of milliseconds (if done correctly), and that is much, much better than having a piece of software in a corrupted state for seconds/minutes/hours.
In a car, there is a mothership board that is orchestrating everything, pinging every module, and ensuring everything is in working order. Just like a kubernetes setup, if any one piece fails to ping or looks off, just reboot it and get it working ASAP.
I believe "offensive" programming is heavily used in automotive. If there is an issue with the connection to the camera, it is better to show nothing than corrupted and potentially misleading images. Better not to try to guess about uncertain throttle position.
Defensive programming can sometimes look like silently ignoring errors. A haphazard test of defensively written code (that, for example falls back to a different encryption scheme or io device) could pass incorrectly. But there is a place for defensive programming too. I think most important is being aware of which is which.
Defensive programming does not mean that you ignore errors. It means that the dev should always expect the worse and decide right away how to deal with it early.
Imagine you have a car that suddenly block and explode each time an unexpected error is encountered. So that you are sure to catch it.
So, you are driving on the highway, then a there a window fuse that blow and because of that your car decide to brake and explode...
Especially in hardware and embedded, you have to expect the unexpected to happen.
Imagine the car will suddenly stop when a lightbulb break or there is a shortcut in windows control. Sure you will know, but you will have 300 000 cars all around the world bricked!