Quote:
Your answer was irrelevant to my question
No, it wasn't. Luc was absolutely spot-on, if a little terse - he probably assumed you knew what you were doing and would understand what he said.
Allow me to expand on his answer:
When you use a
try...catch
in your code and ignore the actual exception you throw away all the information that would tell you exactly what your problem is. You have a
try
block around the whole DB operation, but your
catch
block collects all exception types and discards them in favour of returning a null value.
So if your connection string is wrong - you return null.
If your SP doesn't exist - you return null.
If your SP fails - you return null.
If there is no column of that name returned - you return null.
If ... you get the idea.
If you aren't going to handle the error yourself, don't use a
try...catch
block. Returning a null error code is old-school: the modern thinking is that if you can't deal with it, let the exception filter up to a level that can. That way a multi-layer app can find a problem is -say- the data layer, and "bubble the exception up" through the Business layer to the Presentation layer which is the only one that can let the user know there was a problem - and still access the Exception object to tell him what the problem was!
With your method, your null return tells the calling method that
something went wrong, but gives nobody any idea what it might have been!
Luc's answer wasn't irrelevant - you just didn't understand it.