# Wednesday, December 15, 2004
| Main | What do you want to know about the loade... »

I was reading the CLR newsgroup and noticed the following post about unhandled exceptions. I wasn't quite sure exactly how this worked, so I wrote a quick app that caught exceptions from other domains in the defaul domain. This behaviour was what the poster was looking for.

You can download the code [Everett | Whidbey ] to see how it works.

The basic idea is that you register for the AppDomain.UnhandledException event. This event will be fired for any exception that is not handled in any domain in the process. You cannot swallow the exception at this point, so your app will die no matter what. You can, however, do any cleanup that is required or put up some kind of user notification. In the case below, you can see that I tell the user that an unhandled exception occured. I'm sure that this is going to be quite useful to them ;)

Here is the bulk of the code:

    class Program
    {
        static void Main(string[] args)
        {

            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

            AppDomain domain2 = AppDomain.CreateDomain("domain2");
            domain2.CreateInstance("DomainLib", "DomainLib.ThisClassThrows");

        }

        static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            Exception ex = (Exception)e.ExceptionObject;
            Console.WriteLine("Unhandled exception!!");
            Console.WriteLine(ex.InnerException.Message);
        }
    }

Another option, which is a good idea, is to use try/catch blocks in your code around calls to other domains. That way you can catch the exceptions that come across the domain boundary as opposed to just settle for process termination.

Thursday, January 13, 2005 3:03:41 PM (GMT Standard Time, UTC+00:00)
Confusing. "AppDomain.CurrentDomain.UnhandledException" event seems to indicate it will fire for unhandled exceptions in the current domain. This is not true?
G. Man
Thursday, January 13, 2005 5:33:19 PM (GMT Standard Time, UTC+00:00)
The CLR debugging services has a similar hook which brought out attention to a caveat. Exceptions that truly cross the AD boundary will work fine.
However, imagine if code catches the exception themselves, manually serializes it across the boundary, and then rethrows it on the other side. (This may be done by a 3rd-party library or even the FX).

In this case, exception technicaly didn't cross the boundary, so not firing the hooks is by-design. But an end-user won't realize that their exception is being caught + rethrown like this and so it will appear broken to an end-user. And then we get complaints that the checkbox in the VS debugger for "Stop on AppDomain Unhandled Exceptions" doesn't work. ;)
Thursday, January 13, 2005 5:59:30 PM (GMT Standard Time, UTC+00:00)
Good stuff. I'd love to see some detail about object lifetime in remote domains. My team is struggling through leases, sponsors, and lifetime services for our current project.
Clint Miller
Thursday, January 13, 2005 10:20:50 PM (GMT Standard Time, UTC+00:00)
A limitation of the 1.x CLR is that you can only register for UEs in the default appdomain. If you subscribe to the UE from within a secondary appdomain you will never receive notification that one has occurred; you should at least get an error indication that you can't register. Ideally you should be able to register for and receive UEs in the appdomain in which the handler is registered.

Hopefully this will be addressed in 2.0+ versions of the runtime.
David Levine
Friday, January 14, 2005 5:12:37 PM (GMT Standard Time, UTC+00:00)
Also check out the event on Application object called ThreadException which fires for unhandled exception in current "appliction". It also lets you swallow the exception if you want to.
Tuesday, February 01, 2005 8:42:18 AM (GMT Standard Time, UTC+00:00)
Hi
Can u explain, how to catch exception occurred on other thread?

dhananjay123
Thursday, May 12, 2005 7:49:47 AM (GMT Daylight Time, UTC+01:00)
You just have to hope that 'ExceptionObject' is marked as serializable (a lot aren't despite the guidelines) and that the assembly they're defined in is accessible from the default app domain. These two restrictions make hooking the 'UnhandledException' event cause more problems that it's worth. I now just pretend the 'UnhandledException' event doesn't exist.
Monday, October 17, 2005 11:46:15 AM (GMT Daylight Time, UTC+01:00)
Hello!I found here a plenty of useful information for myself! I will visit you soon...
Monday, October 17, 2005 11:48:16 AM (GMT Daylight Time, UTC+01:00)
The interesting information located on your page
Friday, October 28, 2005 12:35:38 PM (GMT Daylight Time, UTC+01:00)
Hello. I just wanted to give a quick greeting and tell you I enjoyed reading your material
Tuesday, August 07, 2007 8:10:44 AM (GMT Daylight Time, UTC+01:00)
good website,my nice site!
Comments are closed.