An "exceptional situation" is when the software misbehaves. User error does
not constitute an "exceptional situation." Good software *expects* and deals
with user error. Exceptions are expensive in terms of performance. They
should be considered a necessary evil, and therefore, to be avoided when
possible.
Now, as to how to architect your software, there are many ways to skin the
proverbial cat. But if you keep the basic underlying principles in mind, you
will do well. The trick is to know what the underlying principles are, and
to be mindful of them. It is more difficult to work from a basis of
principle than to simply follow a set of pre-written rules. To work from a
basis of principle means that one must calculate the outcome of each
situation based upon all of the underlying principles and factors involved.
The alternative (working from an existing set of rules) is much easier (in
the short run). As humans are inherently lazy, there is often a trend toward
the latter. There are 2 very serious problems with the latter approach,
however:
1. When a situation arises that is outside the bounds of the set of rules
(which will happen eventually), one will not have the understanding of the
underlying principles involved in order to solve the problem correctly.
2. Sets of rules must be memorized, as must underlying principles. However,
where there are relatively few underlying principles, there are many rules
associated with the use of blueprints. In the long run, people often become
so involved with all the rules that they forget the principles.
Case in point: HTML was originally created without extensibility in mind. It
was created with a set of rules. As demand for functionality increased,
more rules were added, and exceptions to those rules proliferated.
Eventually, the rules of HTML became so complex that it is nearly impossible
to parse any HTML document without error. As a reaction to this, XML was
created. XML is strict, and has very few rules. However, like principles,
the rules of XML are without exception. It is nearly infinitely extensible
because it was designed to be so. The DTD used defines the rules of any XML
document, making it self-describing, and independent of any large set of
rules governing all XML documents. Because of this, it is easy to parse any
XML document without error. And it is highly likely that XHTML will
eventually replace HTML worldwide.
There has been a proliferation of patterns and blueprints in the software
world, and many of these have been adopted simply because of their
popularity. They are used without knowledge or understanding by many people.
These patterns and blueprints are sound because they are based upon the
underlying principles. They are simply collections of rules that, within
certain parameters, are derivations of the underlying principles. However,
it is important to note that they are by no means any substitute for
knowledge of those principles. When they become so, these sorts of
Lilliputian arguments are the outcome.
Your instincts are right. All you need to do is to be able to explain what
you're feeling by tying your ideas to the underlying principles, and apply
those principles to a solution.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"cat" <ca*@discussions.microsoft.com> wrote in message
news:95**********************************@microsof t.com...
I had a long and heated discussion with other developers on my team on when
it makes sense to throw an exception and when to use an alternate
solution.
The .NET documentation recommends that an exception should be thrown only
in
exceptional situations. It turned out that each of my colleagues had their
own interpretation about what an "exceptional situation" may actually be.
First of all, myself I'm against using exceptions extensively, because for
complex business applications they make the code very complicated and
because
of a long list of other issues I could post here if someone is interested.
The only arguments pro using exceptions that I was presented were that
they
force the caller to not ignore them and "this is the trend in the industry
so
we must follow".
To exemplify what an exceptional situation might be, we debated a lot on
this piece of code:
protected void login_Click()
{
try
{
UserSession objSession = _manager.StartUserSession(strUsername,
strPassword);
Session["userSession"] = objSession;
}
catch ( InvalidUsernameException ex1 ) // username does not comply to
requirements
{
. further processing
}
catch ( InvalidPasswordException ex2 ) // password does not comply to
requirements
{
. further processing
}
catch ( AuthenticationException ex3 ) // user account not found, locked,
disabled, etc.
{
. further processing
}
catch ( Exception ex4 ) // system error or any other exception we don't
need to handle separately
{
_logger.LogTheError(ex4);
. further processing
}
}
My point was that the above is an example of abusing exceptions as it's
using them for non-exceptional situations, and it's using them exactly
like
some return values. A user mistyping his password is just one of the
alternate paths in a login/authentication use case, it's simply part of
the
flow. It is expected that from time to time users mistype their username,
or
some administrator may lock some account. The counterargument was that
user
providing the proper username and password is the normal case while user
mistyping the username or account being locked is the exception, so we
should
throw an exception in such cases.
I extensively went through all sorts of information and websites and blogs
on the Internet. However, I couldn't find much on such difficult and
important issue. Everybody seems to agree that opening a non-existent file
or
stuffing a non-numeric string into an integer should throw an exception.
But
that's pretty much it. Most of the applications on the market actually
deal
with cases like the above one, yet there is no clear guideline on what
could
justify throwing an exception in a business application and what not. What
is
your opinion?
