Not really.
As others have already said:
Write better/more robust code.
Employee e = Something.GetEmployee();
if(null!=e)
{
//do something with e
}
OR
Employee e = Something.GetEmployee();
if(null==e)
{
throw new ArgumentException ("Employee was expected to be found, but was
not");
}
ArgumentException can/should be replaced with your own custom exception,
like
EmployeeNotFoundException : ApplicationException
...
The better you code, the better your debugging time and maintenance efforts
will be.
...
I just had this happen at work.
I had coded up some xpath/xml code.
I was told "yeah, the xyz attribute will always be there".
I coded to search for the attribute (and its value).
However, I coded it to throw an exception if this attribute was NOT found.
2 days later.
"Your code is blowing up"
"Oh really?"
I check the code, and its working perfectly.
I was like "You said it would always have the xyz attribute".
"It does have the xyz attribute.
We check the Xml.
He had
Xyz in the xml.
Xml is case sensitive.
"Oh , I didn't know xml was case sensitive".
So it was a quick fix. Mainly because I had anticipated the situation, and
wrote the code to handle (or throw an exception) if something was wrong.
It didn't take hours of debugging because I got some "object was null"
exception.
Better code always means faster debugging and maintenance times.