G
Guest
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?
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?