Exceptions in multithreaded application.

I have heard from a very discerning person that an exception being thrown (and not caught) in a thread is being propagated to the parent thread. Is that true? I have tried something like this but couldn't catch the exception in the creating thread.

    static void Main(string[] args)
    {
        ParameterizedThreadStart pts = 
           new ParameterizedThreadStart(ThreadMethod);
        try
        {
            Thread t = new Thread(pts);
            t.Start(new object());
            Console.ReadLine();
        }开发者_JAVA百科
        catch (Exception ex) //the exception is not caught
        {
            Debugger.Break();
        }
    }


    static void ThreadMethod(object @object)
    {
        Thread.Sleep(2000);
        throw new IndexOutOfRangeException();
        Thread.CurrentThread.Abort();
    }

The thread's exception will not propogate to the main thread's context. This really makes sense - by the time the exception is thrown, the main thread will typically be in a completely different scope than the one containing your exception handler.

You can catch these exceptions (typically to log them) by hooking into AppDomain.UnhandledException. See that page for details, including differences in Windows Forms applications, etc.

This is a great article about Threading in C# and how to handle Exceptions

No, it won't. In order to catch thread exceptions you need to use Application.ThreadException.

A decent resource on Threading in C# that has a section for exception handling: Threading in C#

Exception propagate upwards in the call-stack.

If you start a new thread from a certain method, it will propagate upwards until it gets to that method.

If that method doesn't catch it, you'll get a runtime error that there's an uncaught exception.

Here is one way of catching it and handling it in a safe way:

BackgroundWorker bg = new BackgroundWorker();
object o;
bg.DoWork += (c1,c2) =>
{         
        Thread.Sleep(2000);        
        throw new IndexOutOfRangeException();
};

bg.RunWorkerCompleted += (c3,c4) => 
{

 if (((RunWorkerCompletedEventArgs)e).Error != null)
    {
        MessageBox.Show(((RunWorkerCompletedEventArgs)e).Error.Message);
    }
};

In short, no it doesn't. You have a couple of obvious options:#

1. log it out in the method your new thread starts (top of the stack for the created thread) in.
2. Use a construct like Asynchronous delegate, which will will return an exception when you call end invoke, which you can then catch in the normal way.

An exception can only be caught on the thread from which is came. So throwing an exception on another thread won't cause another thread to catch it.

There is no concept of a "parent" thread.

There is a very simple solution for the special case when the main thread waits for the completion of the other thread (see https://msdn.microsoft.com/en-us/library/58195swd(v=vs.110).aspx#Examples). It requires only a class exception variable.

The modified code sample completed by an exception handler may look like this.

using System;
using System.Threading;

class WaitOne
{
    static AutoResetEvent autoEvent = new AutoResetEvent(false);
    static Exception SavedException = null;

    static void Main()
    {
        Console.WriteLine("Main starting.");

        ThreadPool.QueueUserWorkItem(
            new WaitCallback(WorkMethod), autoEvent);

        // Wait for work method to signal.
        autoEvent.WaitOne();
        if (SavedException != null)
        {
           // handle this exception as you want
        }

        Console.WriteLine("Work method signaled.\nMain ending.");
    }

    static void WorkMethod(object stateInfo) 
    {
        Console.WriteLine("Work starting.");

        // Simulate time spent working.
        try
        {
          Thread.Sleep(new Random().Next(100, 2000));
          throw new Exception("Test exception");
        }
        catch (Exception ex)
        {
            SavedException = ex;
        }            

        // Signal that work is finished.
        Console.WriteLine("Work ending.");
        ((AutoResetEvent)stateInfo).Set();
    }
}