The article you linked to is hit-and-miss. It contains some good
advice, but also contains a few bits of bad advice, and I found it
rather difficult to read.
Most of the methods you write will naturally return things. The
properties you write will definitely return things. Most of the time
these will be object references. The usual C# idiom for "information
not available" is to return null. So, in that case, you are doing some
"flow control" based on a return value:
Employee e = Employee.GetEmployee(employeeNumber);
if (e == null)
{
... handle "no such employee" case ...
}
else
{
... found the employee ...
}
A method like GetEmployee() should throw an exception only if something
awful and unexpected happens. Depending upon your design, an invalid
employee number may be commonplace or "awful and unexpected". Design
accordingly.
If you don't know ahead of time how your method is going to be used, so
an invalid employee number may be either "awful and unexpected" or
commonplace, throw an exception but provide a validation method:
if (!Employee.IsEmployeeNumberValid(employeeNumber))
{
... handle invalid employee number ...
}
else
{
Employee e = Employee.GetEmployee(employeeNumber);
...
}
One point on which the article errs is that it shows catch clauses for
the Exception type in several places:
try
{
...
}
catch (Exception ex)
{
...
}
You should (almost) never catch an Exception! (Almost) all of your
catch clauses should catch specific types of exceptions, not the
general Exception type. You shouldn't be catching most exceptions
anyway. Instead, you should let them percolate up the call stack and
catch them in global exception handlers.
I find Microsoft's writeup on exception best practices much more
readable and reliable:
http://msdn.microsoft.com/library/d...l/cpconBestPracticesForHandlingExceptions.asp
