为什么不能在主线程中直接捕获和处理工作线程抛出的异常？

Question

I am reading multithreading in Albahari's c# in a nutshell. He says that if a thread (for example Main thread) creates and starts a worker thread, then an exception thrown by the worker thread cannot directly be caught and handled by the creating thread. Let me quote him verbatim:

"Any try / catch / finally blocks in effect when a thread is created are of no relevance to the thread when it starts executing. Consider the following program:

    public static void Main() 
    {
        try
        {
            Thread workerThread = new Thread (Go);
            workerThread.Start(); 
        }

        catch (Exception ex)
        {  
           // We'll never get here!
           Console.WriteLine ("Exception!");
        }
    }


    static void Go() 
    { 
       
        throw null;     // Throws a NullReferenceException

    } 

Albahari goes on to say that: "The try / catch statement in this example is ineffective, and the newly created thread will be encumbered with an unhandled NullReferenceException. This behavior makes sense when you consider that each thread has an independent execution path."

So here is the crux of my question:

I don't get the relevance of "each thread has an independent execution path". I mean why should it matter if the execution paths are independent? I mean when the workerThread throws an unhandled exception -- why can't the CLR just halt the Main thread and hand over the exception object to the catch block in the Main? What's stopping it??

[NOTES:

1. The other related question How do I handle exceptions from worker threads and main thread in a single catch block? is NOT asking the same question --- and none of the elaborate answers express WHY can't the CLR marshal an unhandled exception from a worker thread to the Main thread
2. Similar question is asked about another language, C++, -- where the answers suggest that it has something to do with the two threads having different stacks and the logical impossibility of mixing the two while unwinding the stack during exception handling. I'm not sure whether those answers apply here to a managed execution environment, like that of c#.
   ]

Answer 1

The main thread might have already finished executing.

I know it is hard to understand at first, but the worker thread is not executed like a method call even if it looks like that. The thread is created inside that try-block, but the execution might happen much later or not at all. Source code in text form can not make this visible. There seems to be some kind of "spacial" proximity of the try-block and the thread, but the moment the thread is created, the spacial proximity is gone. The try block only handles any exceptions that happen while the thread is created, but the it is "detached" from it.

Analogy: The main thread is the manager (team lead) and the worker thread(s) are the workers (team members) reporting to that manager. The workers are working in their home office. In the morning the manager is sending them emails with tasks for the day ("execute method Go"). Since the manager can not see the workers doing their work, she can only notice any progress or lack of it, if the workers send progress reports from time to time. If workers fall off their chairs or down the stairs (exceptions), the manager would not know. The workers need to make sure to catch such exceptions and send an appropriate message to the manager to let her know. The manager is (in this case) not waiting around after sending the initial emails, but is doing other work in the meantime.

Answer 2

You are asking why the CLR can't halt the Main thread, and handle the exception of the child thread. Do you mean the main thread should always suspend execution automatically, immediately after launching a new Thread ? This would be very unhelpful, since a program could then have at a maximum one and only one active thread. It would be the end of multithreading as we know it. So you probably mean that the CLR should offer a mechanism to do this suspension of execution on demand, Although such a mechanism is indeed not available: you can do something very close to it using tasks:

public static void Main()
{
    try
    {
        Task workerTask = new Task(() =>
        {
            throw null;
        }, TaskCreationOptions.LongRunning); // Use a dedicated thread
        workerTask.Start();
        workerTask.Wait();
    }
    catch (Exception ex)
    {
        Console.WriteLine("Exception!"); // It happens!
    }
}