i just realize i should give an example of why it is bad
consider the following code (in c#):
string getnode(string xpath)
{
try
{
return myconfigfile.SelectSingleNode(xpath).Value.ToString();
}
catch
{
return "";
}
}
at first it looks like this is a good routine (a lil lazy written maybe) because whatever happens you always get an empty string instead of an null pointer exception. even if the node did not exist.
but what happens if you feed an invalid xpath string? the routine also returns an empty string! this can cause a lot of things to go wrong in your code, but not at the point where it fails, but later on where the results are used of your code that failed. debugging those errors is a crime.
now look at this code:
string getnode(string xpath)
{
Node mynode = myconfigfile.SelectSingleNode(xpath);
if (mynode == null)
return "";
else
return mynode.Value.ToString();
}
this also returns an empty string if the node doesn't exist, but if you feed it a wrong xpath string this code will crash. so the first time a developer runs his code that calls this function, he will get an warning about invalid xpath syntax.
the try catch unnecesarrily catches all or a subset of errors. by instead checking for the speciffic anticipated situation we were not caught off guard when writing some flawed xpath string.
of course there are situations where this example would not apply at all, but i think it is a good thing to not to write code this way by default
hope this clarifies my view a lil more