Well, that's a tough case especially for debugging.
The only reason strdup would fail in this way is in the case that the process is out of heap memory, right? If you're debugging a process, that error is going to show up in multiple ways (most frequently around a null pointer fault) but most likely in different places.
Checking for errors on allocations like that is a great DEBUGGING strategy. But I think it generally goes above and beyond on code that makes it into a production environment.
When I program I generally go for (in order of importance):
* The ease of changing the code I'm writing.
* The ease of understanding the interfaces to the code I'm writing.
* The correctness of my code with regard to the contracts that it exposes (because if a function says that it will never fail and then fails, I'm not writing my contract correctly).
* The correctness of my code in general.
There are situations where I might have something like this (pseudocode):
re : Regex = "\\d+"
value = re.Match("502blah");
At this point I know "value" is going to contain a string with only numbers in it. .NET provides two utility methods, int.Parse() and int.TryParse(); the former throws an exception and the latter fails with a Boolean result. Typical usage indicates to use TryParse(), but since I've already validated that it will only contain one or more numbers, I can skip it.