[Mono-dev] Unhandled exception behavior

[Massimiliano Mantione]

Hello,
the attached patch fixes bug 82416 (please review...), about how the
runtime
reacts to unhandled exceptions.

Perhaps more interesting than the patch are the tests (attached
archive).

At first, looking at the pages on msdn, the feature seemed really
simple.
Then I begun looking at corner cases, and I wasn't sure how to handle
many of
them, like "is it different if I create the thread before the new
appdomain,
or if I run a new thread inside the new appdomain?", or "what happens if
I
specify a config file with <legacyUnhandledExceptionPolicy enabled="1"/>
for
the new appdomain?"...

The answer I got was always "see what Microsoft does"... and so I did.

I cataloged all the relevant conditions for this feature, which turned
out
being the following:
- runtime version (1.1 or 2.0)
- legacy behavior requested for the app (in the config file)
- throw the exception in a different thread
- throw the exception in a different appdomain
- legacy behavior requested for the different appdomain (in another
config
  file)
- create yet another thread in the different appdomain, and throw the
  exception from there
- add a handler to the root appdomain
- add a handler to the other appdomain

Each variation of these condition creates a new test case... the
conditions
are 8, but some of them cannot be combined (some only make sense if
there
is a new appdomain), so this gives us "only" 144 test cases.

The "relevant behaviors" that must be checked for each test case are the
following:
- if the exit code is 0 or not (the process aborted)
- if the main thread continued after the exception (after the join with
  the thread that threw the exception)
- if the handler in the root domain has been called
- if the handler in the other domain has been called
So, each of the 144 tests passes only if all the four tested conditions
are "correct".
And here, "correct" means "do what the MS CLR does".

Since the tests are so many, I generalized them in one single program
that reacts to its parameters executing one of the test combinations
(see "unhandled-exception-test-case.1.cs").

Then I wrote a "runner" that executes all the tests, and can be run
in two modes:
"GTC:F" actually run the specified tests, and check the results
"GTC:T" just run the tests, and record the results
where "GTC" stands for "Generate Test Configuration".

In "GTC:T" mode, the program prints one line per test which is a call
to the constructor of TestDescription with the correct parameters to
specify the test.
Moreover, in this mode the program actually constructs all the
possible test combinations, so I don't have to write them :-)

The idea is to run it in GTC:T mode on Windows, and collect the results
to build the actual test cases.
As a sanity check, I also tried to run the test in GTC:F mode on windows
with all the 144 tests, and they all passed.

With the attached patch, mono passes all the tests, which means it
behaves just like the MS CLR.

What I sow is that most of the corner cases were silly, and had no
strange behavior.
The <legacyUnhandledExceptionPolicy enabled="1"/> is only accepted for
the whole application, and is valid for the whole runtime: specifying
it in different appdomains has no effect at all.

But one MS behavior is strange: in 2.0, the runtime executes also the
exception handlers added to non-root appdomains, and this is well
documented.
If (in 2.0) you specify <legacyUnhandledExceptionPolicy enabled="1"/>
in the config, the "abort" behavior reverts to the old 1.x one, but
all the handlers are called anyway, so the MS runtime is not "fully"
emulating the legacy behavior :-)

That's it... have fun!
  Massi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: unhandled-exception.patch
Type: text/x-patch
Size: 6865 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070831/6a3d6dd7/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-unhandled-exception.tar.gz
Type: application/x-tar
Size: 51200 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070831/6a3d6dd7/attachment.tar