Without knowing how you are testing this it is impossible to determine
exactly why your results are skewed.
Given the snippet you show below, the catch handler will catch everything
that is thrown on the main thread, even if the exception is not
CLS-compliant (e.g. a library somewhere throws an integer rather then an
exception object). Also, since the catch block is a 'naked' catch, there is
no exception object associated with it, so you will be unable to examine the
cause of the exception.
It is important that you know which exceptions will not be caught;
exceptions thrown on any other thread will not be delivered to the catch
block. Examples of this include exceptions that occur on a threadpool
thread, a thread that you created manually, and also exceptions that occur
in finalizers, as the GC runs finalizers on a separate thread.
Exceptions thrown on the main thread and which are handled somewhere else
(i.e. further down the call stack another piece of code catches the
exception and handles/swallows it) will not be delivered to this catch
block.
Also, the catch handler will never be called unconditionally ...it will only
be executed if an exception occurs on that thread which is not handled
somewhere else.
The finally block will always execute unconditionally , with one
exception....if the application terminates abnormally the finally block will
not run. For example, if some other piece of code calls Environment.Exi t.
Under normal circumstances execution returns from the call to
Application.Run (), and from there execution always continues at the finally
block (or the catch block).
None of these behaviors depends on the type of build...debug versus release.
There are some differences that may show up in edge cases but which are not
likely to effect the code snippet you show below.
For example, the statement
Application.Run (new something());
causes an object of type 'something' to be created, but the reference is not
assigned to a local variable, so the shortest lifetime possible is scoped to
the method call to Run(). When running under the debugger the debugger
typically will report the reference as live until the end of the Main's
method body instead of the call to Run()...this makes it easier to debug as
you can examine the object even after the method call has been completed. In
the release build the object's lifetime may end after the call to Run
returns. If the object has a finalizer then in a release build it could be
run before the finally block that follows the Run(), or in a debug build it
may get called after the finally block runs.
"Robert Rotstein" <rr*******@veri zon.net> wrote in message
news:kh3Ze.2516 $lW3.811@trndny 09...
It appears that exception handling at the top-most level of a C# program,
in the static void Main() method, differs depending on whether the program
is run in debug mode or not. That is, code such as the following
try
{
Application.Run (new something());
}
catch
{
...
}
finally
{
...
}
invokes the catch{} handler (if an exception is thrown somewhere and is
not caught elsewhere) and the finally{} handler only when the program is
run in debug mode. At least, that is the behavior that I have observed.
How do you get the catch{} and finally{} handlers to be invoked
unconditionally , regardless of how the program has been launched?
