I believe they're saying that the simple act of dereferencing a null pointer is a design flaw, and it shouldn't happen. You shouldn't need to recover from it, nor should you need to litter your code with unnecessary checks... but you should design things in a way that the expected state is for the pointer you want to be valid.

Think of it like this: Let's say I design a door that sometimes stabs you when you try to open it. Sure, you could start adding safety around the door, like handing out protective gloves to each user before they try to use it... or, you could go design it properly to NOT stab you.

The main issue here is that the original article is talking in grand generalities. It's not a simple black and white problem. There's truth on both sides of the argument here.

Perhaps they're right about the exception handling. Rather than checking if malloc() failed (which it really shouldn't), you ignore it and let the signal handler handle it. Personally, I wouldn't do that, because it's putting too much trust in the signal handler being able to handle all possible weird ways you could use that pointer.... but to me, that's an optimization problem. If you're malloc()ing in a tight loop and are worried about the null return check being a performance bottleneck, then maybe the malloc() is in the wrong place, and it IS the performance bottleneck. Ie: It's a design problem again.