Use of "try ... catch"

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi, I would like to have some information on how to use try...catch.

I'm trying to simplify the problem in this way: imagine to have a main form
that opens another form in this way:

Form2 frm2=new Form2();
try
{
frm2.ShowDialog();
}
catch (Exception exc)
{
MessageBox.Show("Error: "+exc.Message);
}

Well, if the Form2 produce some error, this will be catched and I see my
error message but I see it just for a second and then the complete
application ends.

In some more complex situation the application crashes and I need to
soft-reset the device; and here I have another problem because all the
Windows CE devices (I'm not talking about PPC) doesn't have an hardware
soft-reset and this means that, if the operatying system crashes because of
my application, I need to hard-reset the device and I will lost everything
that is not saved on flash-disk area.
This is very dangerous for me because to restart I need to install
everything, my application, .NETCF and OpenNETCF.

To avoid this bad situation I would like to understand the better use of
try...catch structure.
In complex situation Form2 can do a lot of things and can have a lot of
functions; every one of this function can produce an error and you know that
it is difficult to control everything. Is it really necessary to put
try...catch everywhere ? Is there a limit on using an high number of
try...catch ?

I hope to have express in a clear way my problem otherwise let me know I
will try to explain it better.

Thank you in advance.

Keven Corazza
 
Maybe it's worth making a difference between (expected) errors and
(unexpected) exceptions. Try to handle errors without using try / catch
e.g. using code like

Process(data, out error);
if (error == None) {
// ...
} else {
// show msg, recover from error
}

Exceptions are rather expensive at runtime and can make it difficult to
follow a program's control flow when looking at it's code. They should
not be shown to an end user in detail but rather be logged to a file
before the application is terminated. Note: Even if your program is
correct an exception is always possible (e.g. lack of memory).

Concerining the allowed depth of try / catch blocks the spec might
help:
http://www.ecma-international.org/publications/standards/Ecma-334.htm
 
Thank you for your answer but your suggestion is obvious. The problem is
manage unexpected error or exceptions; in big project you insert many errors
in your code and you cannot see them until you execute the application and
execute some specific operations.

So try/catch are very useful the problem is that seems that they doesn't
allow to manage the exceptions completely, I mean after the exception is
managed the application is not able to continue its normal execution but exit
or crashes the system.

Keven Corazza
 
First, in my above (intentionally coarse) definition "unexpected
errors" do not exist. Second during development it should be no problem
letting exceptions bubble up (i.e. not catching them). Further, it does
not seem to be good practice continuing program execution after an
exception because the program might be in an inconsistent state.
 
Hi,
I can't fully explain why but from may experience when an exception that
occurs in an event handler is not catch eventually the application will
crash even if you catch the exception at a higher level, like in your
example:
Form2 frm2=new Form2();
try
{
frm2.ShowDialog();
}
catch (Exception exc)
{
MessageBox.Show("Error: "+exc.Message);
}

so in order to avoid this you must ensure that exception all handled in all
event handler (button click, Selection changed, Form load etc ...)

Marius
 
Back
Top