Alternative to Exception Handling

[Bry]

I've created a class that offers an enhanced way of handling fatal
exceptions. The class allows the user to optionaly submit a http based
anonymous error report to myself, and also records details in the
application log. The static method is overloaded, and supports passing
exceptions and/or strings just like throwing an exception.The class
will also fall back to the standard exception handling if something
goes wrong in my class.

As an example of how I use my exception class, I might use something
like this

try
{
// This code should throw an exception

int a = 1;
int b = 0;
int c = a / b;
}
catch (DivideByZeroException ex)
{
EnhancedException.Generate("Application Name", ex);
}

The question is, after my code has dealt with the exception, is it safe
for me to use Enviroment.Exit(1); rather than throwing another
exception to exit my app?

Throwing another exception would confuse the user (seeing my exception
dialog, followed by the system exception dialog)

Note that I only intend to use this in WIndows forms applications.

[sloan]

See this post:
http://groups.google.com/group/micro...6814ee621cb99c
Or
http://groups.google.com/groups/sear...tup+form+is%22
This will catch any un caught exceptions, and allow you to provide a
friendly message to your user.


"Bry" <br*********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

I've created a class that offers an enhanced way of handling fatal
exceptions. The class allows the user to optionaly submit a http based
anonymous error report to myself, and also records details in the
application log. The static method is overloaded, and supports passing
exceptions and/or strings just like throwing an exception.The class
will also fall back to the standard exception handling if something
goes wrong in my class.

As an example of how I use my exception class, I might use something
like this

try
{
// This code should throw an exception

int a = 1;
int b = 0;
int c = a / b;
}
catch (DivideByZeroException ex)
{
EnhancedException.Generate("Application Name", ex);
}

The question is, after my code has dealt with the exception, is it safe
for me to use Enviroment.Exit(1); rather than throwing another
exception to exit my app?

Throwing another exception would confuse the user (seeing my exception
dialog, followed by the system exception dialog)

Note that I only intend to use this in WIndows forms applications.

[Dave Sexton]

Hi,

The question is, after my code has dealt with the exception, is it safe
for me to use Enviroment.Exit(1); rather than throwing another
exception to exit my app?

It depends on what you mean by "safe" and what you expect the Exit method to
actually do.

Environment.Exit will immediately stop the process, while Application.Exit
performs a more graceful shutdown of all message loops in the application,
giving each Form the chance to cancel the entire shutdown process if
necessary.

Throwing another exception would confuse the user (seeing my exception
dialog, followed by the system exception dialog)

Do you really want to exit the application when a DivideByZeroException is
caught?

In other cases, where the Exception is critical and cannot be handled by the
application or the end-user, you may want to display a custom dialog and then
exit immediately after, as you've suggested. Throwing another exception just
to exit the application isn't a good idea, IMO.

--
Dave Sexton

"Bry" <br*********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

I've created a class that offers an enhanced way of handling fatal
exceptions. The class allows the user to optionaly submit a http based
anonymous error report to myself, and also records details in the
application log. The static method is overloaded, and supports passing
exceptions and/or strings just like throwing an exception.The class
will also fall back to the standard exception handling if something
goes wrong in my class.

As an example of how I use my exception class, I might use something
like this

try
{
// This code should throw an exception

int a = 1;
int b = 0;
int c = a / b;
}
catch (DivideByZeroException ex)
{
EnhancedException.Generate("Application Name", ex);
}

The question is, after my code has dealt with the exception, is it safe
for me to use Enviroment.Exit(1); rather than throwing another
exception to exit my app?

Throwing another exception would confuse the user (seeing my exception
dialog, followed by the system exception dialog)

Note that I only intend to use this in WIndows forms applications.

[Bry]

Thanks for the replies.

Sloan: I wondered about putting a general catch all handler in place,
but I tend to use lots of individual try/catch blocks around anything
that might throw an exception. I might try putting a try/catch around
Application.Run and individual try/catch around other blocks of code
where an exception can be handled better.

Dave: You are quite right, DivideByZero could be handled better, it was
just the first way of generating an exception that came in to my head -
Bad example on my part.

I guess Environment.Exit is better when dealing with fatal exceptions.

[Dave Sexton]

Hi,

Sloan: I wondered about putting a general catch all handler in place,
but I tend to use lots of individual try/catch blocks around anything
that might throw an exception. I might try putting a try/catch around
Application.Run and individual try/catch around other blocks of code
where an exception can be handled better.

You really shouldn't catch exceptions that "might" be thrown unless you can
handle them gracefully in code.

Check out the following article for the recommended "local" exception handling
procedures:

"Exception Handling"
http://msdn2.microsoft.com/en-us/lib...05(VS.80).aspx

Adding an event handler to AppDomain.CurrentDomain.UnhandledException is a
good place to catch all instead of wrapping Application.Run in a try...catch.

You might rather use a pre-built library to handle exceptions on a "global"
level:

"Exception Handling Application Block"
http://msdn.microsoft.com/library/de.../html/ehab.asp

Dave: You are quite right, DivideByZero could be handled better, it was
just the first way of generating an exception that came in to my head -
Bad example on my part.

I guess Environment.Exit is better when dealing with fatal exceptions.

In most cases you won't be able to do much with true "fatal" exceptions, so
don't worry about those and just worry about the exceptions that you can
handle, even at the AppDomain level. For instance, what do you expect to do
when an OutOfMemoryException, ExecutionEngineException or
StackOverflowException is thrown?

If one of the aforementioned exceptions is thrown then your application might
just blow up but there's nothing you can really do in terms of "handling"
those exceptions so neither Application.Exit or Environment.Exit should need
to be called. In most other cases you will probably be able to at least log
the exception and try to continue running the application, but it's doubtful
that you'll be able to determine whether there will be any loss of state from
within a "global" exception handler. Therefore, calling Application.Exit will
at least allow your Forms one last change to gracefully shutdown if you must
shutdown the application (but I'd question your reasoning for doing so in the
first place).

I don't think you should worry about trying to end the application in code.
Instead, worry about how to safely keep it running.

--
Dave Sexton

"Bry" <br*********@gmail.comwrote in message
news:11**********************@f16g2000cwb.googlegr oups.com...

Thanks for the replies.

Sloan: I wondered about putting a general catch all handler in place,
but I tend to use lots of individual try/catch blocks around anything
that might throw an exception. I might try putting a try/catch around
Application.Run and individual try/catch around other blocks of code
where an exception can be handled better.

Dave: You are quite right, DivideByZero could be handled better, it was
just the first way of generating an exception that came in to my head -
Bad example on my part.

I guess Environment.Exit is better when dealing with fatal exceptions.

[sloan]

Do a google search for

Brad Abrams try finally

He recommends using more

try
{}
finally
{}

instead of
try
{}
catch{}
finally{}
It not fruitful to catch an exception if you're not really going to do
anything with it, except rethrow it.


"Bry" <br*********@gmail.comwrote in message
news:11**********************@f16g2000cwb.googlegr oups.com...

Thanks for the replies.

Sloan: I wondered about putting a general catch all handler in place,
but I tend to use lots of individual try/catch blocks around anything
that might throw an exception. I might try putting a try/catch around
Application.Run and individual try/catch around other blocks of code
where an exception can be handled better.

Dave: You are quite right, DivideByZero could be handled better, it was
just the first way of generating an exception that came in to my head -
Bad example on my part.

I guess Environment.Exit is better when dealing with fatal exceptions.