After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that was a long time ago), I figured that there's a hierarchy of probable causes of bugs, from most probable:
1. The code I wrote [you must understand only your code]
2. A 3rd-party library/dependency [you must understand your dependencies]
4. The compiler [you must understand the compiler-generated code]
5. The OS, or OS-provided library [You must be intimately familiar with OS internals]
6. CPU, or other hardware-related [You must be intimately familiar with how the CPU or other HW works]
It's basically arranged according to how many other programs are using the given facilities. Returning to the "buggy malloc", I did not dismiss his theory outright just pointed out that if malloc were bugged in such an elementary fashion, that no other programs could work, hence there was overwhelming probability of his code being bugged, not malloc.
---
Just like security features, error-handling cannot be bolted on afterwards. Robust programs begin with defining error-handling strategies and expected outcomes in case of errors and building the rest on top.
---
I could probably go on, but... meh.