469,950 Members | 2,061 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,950 developers. It's quick & easy.

Thoughts on throwing exceptions vs putting them on a property

GG
Any thoughts on designing classes wheather to throw the exception and
the consumer has to capture it on try catch or wrap all the methods in a
main method
This is the wrap logic
MainMethod{
bool mainRun = false;
try
{
methods...
mainRun = true;
}
catch(Exception e)
{
this.errMessage=e.Message.ToString();
}
return mainRun;
}
and consumer just checks if true or false and if false display the
exception?
MessageBox.Show
Class obj = new class
if (!obj.MainMethod())
MessageBox.Show (obj.ErrMessage)

Thanks
*** Sent via Developersdex http://www.developersdex.com ***
Sep 1 '06 #1
5 1323
What if another consumer wants to use the code in a context where opening a
messagebox would not be the preferred way of handling the exception? Say for
instance the code were to be reused in an ASP.NET app ... Is the code in
question already tightly coupled to winforms?

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<GGwrote in message news:Ol*************@TK2MSFTNGP05.phx.gbl...
Any thoughts on designing classes wheather to throw the exception and
the consumer has to capture it on try catch or wrap all the methods in a
main method
This is the wrap logic
MainMethod{
bool mainRun = false;
try
{
methods...
mainRun = true;
}
catch(Exception e)
{
this.errMessage=e.Message.ToString();
}
return mainRun;
}
and consumer just checks if true or false and if false display the
exception?
MessageBox.Show
Class obj = new class
if (!obj.MainMethod())
MessageBox.Show (obj.ErrMessage)

Thanks
*** Sent via Developersdex http://www.developersdex.com ***

Sep 1 '06 #2
It is very easy to accidentally forget to check a return code, where-as
exceptions hit you squarely between the eyes. This is a good thing.

Also - what if you need to return a value from the function? Yes you
can add "out" params, but this is more of a pain to work with. With an
exception you also have more of a clue *what* failed. A boolean just
tells you it bombed; a PermissionDenied exception with a message, an
inner exception (chain) and a stack trace tells me everything I need to
a: inform the user, and b: log the problem for debugging purposes.

Marc

Sep 2 '06 #3
There are many reasons why this is not the mechanism that should be used to
report errors.

1. By default, if the user of the class does nothing the error is lost or
unnoticed. With exceptions if nothing is done then the exception continues
up the call stack until a handler is found or it is unhandled and the system
takes over.
2. The exception type, which can provide valuable diagnostic or recovery
options, is lost. The ability to perform specific error recovery is no
longer possible.
3. It requires the client to check for error returns after every line of
code that uses this class. This is very error prone and is easy to miss an
error return.
4. The client no longer has the abilty to customize the display message.
There may be security sensitive information in the Message field itself,
your routine does nothing to capture the messages of any inner exceptions,
and there may be other data captured in the exception object that the user
wants to display or record.
5. The stack trace is lost.
6. It forces the immediate user of the class to perform error handling
itself, when a proper design may call for error handling to occur higher up
the call stack in a different logical part of the application.
7. It mixes two completely different systems of handling errors - exception
handling and checking for error returns. This causes confusion for clients
using the class as they can never be completely sure which mechanism they
need to use, so they will always use both.
8. Information will be lost when converting between error return values and
exception objects.
9. It increases the amount of code the user has to write and makes it harder
to understand/maintain. More LOC for error value checking must be written as
opposed to the simpler flow of exception-based code writing.

There are many other reasons but I think these hit the high points.
<GGwrote in message news:Ol*************@TK2MSFTNGP05.phx.gbl...
Any thoughts on designing classes wheather to throw the exception and
the consumer has to capture it on try catch or wrap all the methods in a
main method
This is the wrap logic
MainMethod{
bool mainRun = false;
try
{
methods...
mainRun = true;
}
catch(Exception e)
{
this.errMessage=e.Message.ToString();
}
return mainRun;
}
and consumer just checks if true or false and if false display the
exception?
MessageBox.Show
Class obj = new class
if (!obj.MainMethod())
MessageBox.Show (obj.ErrMessage)

Thanks
*** Sent via Developersdex http://www.developersdex.com ***

Sep 2 '06 #4

GG wrote:
Any thoughts on designing classes wheather to throw the exception and
the consumer has to capture it on try catch or wrap all the methods in a
main method
This is the wrap logic
MainMethod{
bool mainRun = false;
try
{
methods...
mainRun = true;
}
catch(Exception e)
{
this.errMessage=e.Message.ToString();
}
return mainRun;
}
and consumer just checks if true or false and if false display the
exception?
MessageBox.Show
Class obj = new class
if (!obj.MainMethod())
MessageBox.Show (obj.ErrMessage)
The answer to this one is that there are errors and there are errors.

As several in this newsgroup have pointed out, this is the wrong
strategy for fatal errors: the types of errors that indicate that
something has gone seriously wrong with your application or the
environment in which it's running. Examples of this might include "out
of memory," "network is down," "database is inaccessible," "table not
found in database," or any number of other serious problems. In these
cases you should throw exceptions.

However, the other posters are dead wrong if the "error" in question is
a normal, expected part of the way your application runs. The most
common example of this being anything that the user does. If the user
types garbage into the "customer name" field, or orders an item that is
out of stock, or makes an invalid request, then these are (from the
user's point of view) errors, but are (from the application's point of
view) business as usual.

In these sorts of cases, your approach has much merit. I use a similar
approach (I return the error string as a return value; an empty string
means "no error".) In addition, in these cases exceptions are the wrong
thing to use, as the situations aren't really "exceptional". As a rule
of thumb, the user should not be able to provoke exceptions within the
application, except by doing physically nasty things like unplugging
network cables.

However, as is usual in programming, it's never quite that easy. There
are many cases in which you don't know, while writing some utility
class, whether a particular condition will be a true error or something
that the application will consider "business as usual" and want to
handle. Sometimes application-level concerns don't translate neatly
across the layers of software. In these cases, it's usually safest to
make the thing an exception, and then catch in those cases in which it
turns out to be "business as usual." Either that, or do what MS did
with their .Parse() routines: add another routine to test for an error
before calling the real routine. Notice that in .NET 2.0 they added
TryParse() all over the place, specifically to address this issue. In
that sense, .TryParse() is like your "return a result" regimen, while
..Parse() throws an exception, and they're meant to be used together.

Sep 4 '06 #5
GG
Thank you all for your thoughts.
*** Sent via Developersdex http://www.developersdex.com ***
Sep 5 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

39 posts views Thread by Marco Aschwanden | last post: by
5 posts views Thread by ChessManiac | last post: by
21 posts views Thread by mihai | last post: by
40 posts views Thread by Kevin Yu | last post: by
15 posts views Thread by Sek | last post: by
4 posts views Thread by Jay Dee | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.