Exception handling suggestions

[Zytan]

Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullExc eption, FormatException , OverflowExcepti on

I don't want my program to just crash on an exception, so I must
handle all of them. I don't care about which one happened, except to
write out exception.Messa ge to a log file. It seems verbose to write
out three handlers that all do the same thing. So, I could just catch
Exception. But, is that recommended? It'll catch everything, even
out of memory exceptions.

What do you suggest?

Zytan

[VJ]

main
{
AppDomain.Curre ntDomain.Unhand ledException+=n ew
UnhandledExcept ionEventHandler (CurrentDomain_ UnhandledExcept ion);
Application.Run (new MyFirstForm());
}

private static void CurrentDomain_U nhandledExcepti on(object sender,
UnhandledExcept ionEventArgs e)
{
// The app shuts down.., you can log here..
//After log exit
Application.Exi t();

}

That should take care of it..
VJ

"Zytan" <zy**********@y ahoo.comwrote in message
news:11******** **************@ q40g2000cwq.goo glegroups.com.. .

Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullExc eption, FormatException , OverflowExcepti on

I don't want my program to just crash on an exception, so I must
handle all of them. I don't care about which one happened, except to
write out exception.Messa ge to a log file. It seems verbose to write
out three handlers that all do the same thing. So, I could just catch
Exception. But, is that recommended? It'll catch everything, even
out of memory exceptions.

What do you suggest?

Zytan

[Zytan]

main

{
AppDomain.Curre ntDomain.Unhand ledException+=n ew
UnhandledExcept ionEventHandler (CurrentDomain_ UnhandledExcept ion);
Application.Run (new MyFirstForm());
}

private static void CurrentDomain_U nhandledExcepti on(object sender,
UnhandledExcept ionEventArgs e)
{
// The app shuts down.., you can log here..
//After log exit
Application.Exi t();
}

Wow, thanks, VJ. Ok, so what is Application? Is that a name you
made? I am testing this in a console app, and it doesn't exist.

Also, I can't actually test this code, since the debugger always halts
the program on an unhandled exception. How do you test this?

Actually, I was thinking about how do I handle exceptions in which I
don't want the program to quit? For example, for int.Parse(), I just
want to catch everything, and keep the program running, since the data
passed into Parse() could possible be improper, so I want to catch it,
and notify me, but continue running. Is catching Exception really a
good idea?

Zytan

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Zytan wrote:

Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullExc eption, FormatException , OverflowExcepti on

I don't want my program to just crash on an exception, so I must
handle all of them. I don't care about which one happened, except to
write out exception.Messa ge to a log file. It seems verbose to write
out three handlers that all do the same thing. So, I could just catch
Exception. But, is that recommended? It'll catch everything, even
out of memory exceptions.

What do you suggest?

Zytan

If the string really can be null, that is easy to check for. You should
check that before calling the method instead of waiting for the exception.

If you don't really need to determine the exact reason why the string
can't be converted, you can use the int.TryParse method instead. Then
you will not need any exception handling at all.

--
Göran Andersson
_____
http://www.guffa.com

[Zytan]

If the string really can be null, that is easy to check for. You should

check that before calling the method instead of waiting for the exception.

Actually, I just do:
int result = int.Parse("0" + s);
so, nulls are handled already.

I'm concerned with s == "ABC". The data that s can be may be warped
sometimes, and this is actually a decent spot to check to ensure it is
not warped.

If you don't really need to determine the exact reason why the string
can't be converted, you can use the int.TryParse method instead. Then
you will not need any exception handling at all.

Ah, ok, thanks, Göran!

Zytan

[VJ]

yes as Goran says its better to safe, than sorry.. but again what I gave is
unexpected situations at a global level.. That is provided by the .NET
environment, for windows applications. Also as note... each try/catch block
is expensive so try to minimze them, and check your parameters before you
execute.

For a console app.. not sure if there one such, my expertise is limited
there..sorry i cant help much.

VJ

"Zytan" <zy**********@y ahoo.comwrote in message
news:11******** **************@ j27g2000cwj.goo glegroups.com.. .

If the string really can be null, that is easy to check for. You should
check that before calling the method instead of waiting for the exception.

Actually, I just do:
int result = int.Parse("0" + s);
so, nulls are handled already.

I'm concerned with s == "ABC". The data that s can be may be warped
sometimes, and this is actually a decent spot to check to ensure it is
not warped.

If you don't really need to determine the exact reason why the string
can't be converted, you can use the int.TryParse method instead. Then
you will not need any exception handling at all.

Ah, ok, thanks, Göran!

Zytan

[Zytan]

yes as Goran says its better to safe, than sorry..

I agree, and thus my post. I don't want to just handle
FormatException , when int.Parse can throw 3 different exceptions.
But, int.TryParse is perfect!

but again what I gave is
unexpected situations at a global level..

Right. What I want to know is how do I handle the exceptions that may
possibly be thrown from each function that has a change of throwing.
Like, for my int.Parse, the data could be garbled, so ALL exceptions
COULD happen. For other functions, network problems could throw
exceptions. I need to therefore test them all. And I've heard
cacthing Exception is bad, since because it gets them all, it gets out
of memory exceptions, as well, which is no good.

But, your solution is the solution to what to do with those out of
memory exceptions that are not caught (since we don't catch
Exception), and then the log can be written, error report sent home,
and gracefully exit.

Also as note... each try/catch block
is expensive so try to minimze them, and check your parameters before you
execute.

Yes, thanks. In the int.Parse case, it could be anything. So,
int.TryParse is what is needed to do the check. And no exception!

For a console app.. not sure if there one such, my expertise is limited
there..sorry i cant help much.

Well, ok, I am making a windows app, but i test in console. So, your
code compiles as-is in a windows app? I will try it.

Zytan

[Zytan]

main

{
AppDomain.Curre ntDomain.Unhand ledException+=n ew
UnhandledExcept ionEventHandler (CurrentDomain_ UnhandledExcept ion);
Application.Run (new MyFirstForm());
}

Ok, if this is for a windows app, what is "main"? The main form's
constructor? After InitializeCompo nent? No it can't be, because you
are running the first form from this. Ah, it's in Program.cs! So, I
have to change this file, and add that event handler addition line, I
see.

Ok, Application.Run (new MyFirstForm()) does work here! It doesn't in
a console app. It is really System.Windows. Forms.Applicati on. I see.

private static void CurrentDomain_U nhandledExcepti on(object sender,
UnhandledExcept ionEventArgs e)
{
// The app shuts down.., you can log here..

//After log exit
Application.Exi t();
}

I presume this code must also go in Program.cs?

It works! The code is run before the debugger tells me the exception
is unhandled! So, i can test it! Thanks, VJ!

Zytan

[Bruce Wood]

On Mar 11, 5:30 pm, "Zytan" <zytanlith...@y ahoo.comwrote:

main
{
AppDomain.Curre ntDomain.Unhand ledException+=n ew
UnhandledExcept ionEventHandler (CurrentDomain_ UnhandledExcept ion);
Application.Run (new MyFirstForm());
}

Ok, if this is for a windows app, what is "main"? The main form's
constructor? After InitializeCompo nent? No it can't be, because you
are running the first form from this. Ah, it's in Program.cs! So, I
have to change this file, and add that event handler addition line, I
see.

You can add the event handler anywhere, but it's best to do it as
early as possible so that the minimum amount of code runs before the
handler is hooked up.

There is also the Application.Thr eadException event. I always handle
them both.

http://msdn.microsoft.com/library/de...ptiontopic.asp

Main, by the way, is the main entry point into any application,
console or WinForms. It is usually the first piece of your code that
the CLR calls, and it's usually where you set up global exception
handlers.

Ok, Application.Run (new MyFirstForm()) does work here! It doesn't in
a console app. It is really System.Windows. Forms.Applicati on. I see.

private static void CurrentDomain_U nhandledExcepti on(object sender,
UnhandledExcept ionEventArgs e)
{
// The app shuts down.., you can log here..

//After log exit
Application.Exi t();
}

I presume this code must also go in Program.cs?

Well, not necessarily. For example, I have mine in a standard error
logging class, and from my Main I call something like:

ErrorLog.Instan ce.SetupConsole ErrorHandling() ;

and inside there I subscribe to the events and the ErrorLog class
contains the event handler methods. Nonetheless, that's just because I
wanted a reusable utility. You can also have the method in your main
program .cs file. Nothing wrong with that.
Finally, I would like to offer some general advice on catching
exceptions: catch only what you can handle. Or, put another way, don't
catch an exception unless you can take some substantial action
regarding it. There are other threads in this newsgroup on exception
handling... when and how to catch an exception, but I wanted to point
that out because it explains why you (almost) never catch (Exception
ex): because it's very rare that you can take some intelligent action
with any exception that could possible happen.

The exception to that rule, of course, being logging, and that's what
global exception handlers are for.

[Zytan]

You can add the event handler anywhere, but it's best to do it as

early as possible so that the minimum amount of code runs before the
handler is hooked up.

Yes, so that it's set up to handle an exception even from the
initialization code you have.

There is also the Application.Thr eadException event. I always handle
them both.

http://msdn.microsoft.com/library/de...ary/en-us/cpre...

Ok, I'll look into that. What are ThreadException s? Like when a GUI
control is attempted to be accessed by another thread?

Main, by the way, is the main entry point into any application,
console or WinForms. It is usually the first piece of your code that
the CLR calls, and it's usually where you set up global exception
handlers.

Right, I should have known that, but I didn't know where it was hidden
in the Windows app.

I presume this code must also go in Program.cs?

Well, not necessarily. For example, I have mine in a standard error
logging class, and from my Main I call something like:

ErrorLog.Instan ce.SetupConsole ErrorHandling() ;

Ok, I just placed mine elsewhere, and it works, as long as I give
Program class access to it.

Hmm, I jus tested my program with Ctrl+F5 (not F5 debug), and an
unhandled exception window pops up. It appears that my handler
doesn't run. But, it does run if I used F5 debug. Strange.

and inside there I subscribe to the events and the ErrorLog class
contains the event handler methods. Nonetheless, that's just because I
wanted a reusable utility. You can also have the method in your main
program .cs file. Nothing wrong with that.

Right, but its best to have a unit handle this that can be reused, I
agree. So, your ErrorLog class adds the handler, and hopefully this
code is run before any other code that could throw an exception.

Finally, I would like to offer some general advice on catching
exceptions: catch only what you can handle. Or, put another way, don't
catch an exception unless you can take some substantial action
regarding it. There are other threads in this newsgroup on exception
handling... when and how to catch an exception, but I wanted to point
that out because it explains why you (almost) never catch (Exception
ex): because it's very rare that you can take some intelligent action
with any exception that could possible happen.

Yes, I agree. And my main concern was exceptions for things that are
bound to happen, such as int.Parse() or dealing with network traffic,
who knows what data may be passed into these functions, or what
network errors may result. So, in these case, I do want to handle ALL
errors gracefully. But, it seemed ugly to write 5 exceptions handlers
OR catch all excpetions with catch (Exception ex). For int.Parse, I
can use int.TryParse. For networkd traffic, it really seems ok to
catch everything. It'd be different if all the possible exceptions
were under the same exception type, but they are not.

The exception to that rule, of course, being logging, and that's what
global exception handlers are for.

Right.

Zytan