Dan, I haven't read the other thread to which you refer, but I might be able
to help a bit with your question...
In my opinion, I don't think your Find method should throw a
NotFoundException. I know the definition of "failure" is subjective, but in
your example, I don't think the Find method failed to find anything; I think
it *successfully found nothing*. This may sound like it's splitting hairs,
but I do think it illustrates a key distinction.
See, I believe that exceptions should be used when a method fails to perform
its basic function for some reason. So, if the Find couldn't even begin
because a database connection wasn't available or a specified directory path
didn't exist, then an exception should be used. But if the search completed
successfully, but it just so happened that nothing was found, the method did
not fail. In a sense, the search failed, but the search *method* didn't
fail.
The condition of no results being found for a search is a normal outcome of
a Find method. In other words, it's not an exceptional result. Now, if the
search can't even start, now *that's* an exceptional situation and deserves
an exeption. Again, my rule of thumb is to limit exceptions to events that
prevent a method from performing its function, not to convey a normal result
(even if that result is negative).
- Mitchell S. Honnert
"Dan Holmes" <da*******@bigfoot.com> wrote in message
news:eR**************@TK2MSFTNGP04.phx.gbl...
In one of the other threads it was mentioned that using return values from
methods to indicated success/failure of the method should be replaced with
throwing exceptions. Which would mean code like:
List l = object.Find(...);
if (l == null) ... //nothing returned
would be replaced with:
try{
List l = object.Find(...);
...
}
catch (NotFoundException ex)
{
}
catch (Exception ex)
{
}
Is this the preferred method? And what is the background on this?
dan