I use defensive programming;
-by proper unit testing while developing a particular module.
-by proper comment lines (for behavior of respective function/ method) and regions.
and of course, meaningful naming conventions (by which one should easily come to know what's its use) all over in application.
I had a boss at one time like that. His code constantly crashed in production. It took the team over month with overtime, to fix one of his projects that he developed, using his leet and fast programming skills.
Let's say I build a function that takes an Object as parameter and the Object is Nothing/null... Don't you want/need to throw a ReferenceNullException? Not doing so and pretending everything went well seems like a code smell to me (and I've worked with code that does exactly that). If the programmer fails to Catch the Exception that's his problem, not mine. If the state of my Class/Library becomes inconsistent as a result of an Exception then that's my problem, but even more the programmer's who uses it
Maybe I'm misunderstanding the concept and I should take judo lessons...