CODEWITHSUNDEEP
c#.netmultithreadingexception
Matt
Matt

Reputation: 1704

Catching exceptions without a catch block

I'm working in a legacy project (read: refactoring is not an option) that is throwing ApplicationExceptions.

throw new ApplicationException(string.Format("More than one type found with the name {0} in {1}", typeName, assemblies));

Context

I'm a relatively new dev. Basic throwing/catching exceptions explicitly makes sense to me. Even the concept of exceptions bubbling up the call stack to a different catch statement feels intuitive.

Beyond that I know the CLR is capable of.. something. This line is particularly confusing (from this article)

The exception is passed up the stack until the application handles it or the program terminates.

I cannot find a single catch statement in this entire solution, which would leave me to think that the exception would terminate the process, but I'm seeing an error message on the front end instead - process runs on.

The top of my call stack is spinning up a new thread and above that is external code. I would show more code if it weren't proprietary.

Dim installThread As New Thread(CType(Sub() InstallPackageAsyncInner(appsToOverride, package, parameters), Threading.ThreadStart))

The Question

Is it possible that the thread that was spun up died, and the parent thread is what's ultimately propagating an error message and processing the exception?

If so, how does this transfer of control take place in .NET or whatever relevant technology handles it?

Upvotes: 1

Views: 121

Answers (2)

antiduh
antiduh

Reputation: 12427

If you're throwing exceptions on the UI, the the call stack has a try-catch frame on it from System.Windows.Forms.NativeWindow.Callback, which is usually the root of the UI thread:

    private IntPtr Callback(IntPtr hWnd, int msg, IntPtr wparam, IntPtr lparam) {

        // Note: if you change this code be sure to change the 
        // corresponding code in DebuggableCallback below!

        Message m = Message.Create(hWnd, msg, wparam, lparam);

        try {
            if (weakThisPtr.IsAlive && weakThisPtr.Target != null) {
                WndProc(ref m);
            }
            else {
                DefWndProc(ref m);
            }
        }
        catch (Exception e) {
            OnThreadException(e);
        }
        finally {
            if (msg == NativeMethods.WM_NCDESTROY) ReleaseHandle(false);
            if (msg == NativeMethods.WM_UIUNSUBCLASS) ReleaseHandle(true);
        }

        return m.Result;
    }

From there, it invokes the Application.ThreadException handler. A default handler is installed that informs you of the exception. After that, the exception is usually swallowed and your UI is given the chance to continue running.

Upvotes: 1

Matt
Matt

Reputation: 1704

The exception handling must be happening at the AppDomain level (as I am running .NET 4.5.1).

Ultimately the AppDomain is what manages the various threads and handles the flow of control in this scenario.

Upvotes: 0

Related Questions