B
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.
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.