Sorry, I forgot to mention that it a console application. How would I
do it in this case? Invoke a delegate on a main thread from another
thread?

To elaborate and add some friendly amendments, exceptions come in
different flavors:

If your exception is, "some resource that I expected isn't available,"
the main thread may be able to fix that by restarting the resource and
re-spawning the background process. This requires that the main thread
know how to and be capable of restarting failed processes.

If the exception is, "the user gave me some data to process that has
errors," the main thread -- a UI thread, probably -- would be the only
one who could fix it, generally by informing the user that their data
doesn't compute and asking them to retry. This requires saving user
input and letting the user modify it and resend.

If the exception is, "something I didn't expect happened," chances are,
no one's going to be able to fix that. It should bubble up, therefore
being caught at the thread boundary and possibly rethrown (you're
right: it's dangerous to just rethrow, but also sometimes appropriate)
or repackaged and thrown upwards. A good example of this is running out
of memory or disk space. Rarely can you do more than tell the user what
happened.

This is part of the reason one should avoid catching Exception.
Instead, it's better to catch specific exceptions and know what each
one means. On a background thread boundary, however, it's often useful
to catch Exception after everything else, just in case something slips
through, so it's not lost in ether.

On the other hand, if you're not going to do anything other than kill
the background process if there's an exception, you might as well not
catch it. Don't catch anything you're not going to use, and never do
the following:

try { ... }
catch { throw; }

That's nothing more than a waste of the overhead of a try/catch block.
If nothing else, put some diagnostic information somewhere so that
someone who knows what they're doing can inspect it and deduce what
happened.

Stephan

Thank you for the detailed replies. Just to make things more clear, all
I actually wanted to do is, in case in one of the backround threads
occurs an excpetion I want to terminate that thread and the main thread
(it has to be the main thread that does that) needs to write details of
the exception to a logstream. What would be a good approach to
implement this. Is introducing the afore mentioned messagepump the
best/only option I have?

I did some more thinking on this.  I misspoke.  My solution already
already guarentees relative ordering for every thread.  That's because
it's impossible for a thread to enqueue messages out of order relative
to itself.  And since there's only one thread dequeueing it's
impossible for them to be dequeued out of order.

Hmm...I sort of agree.  I do disagree on one important point.  No one
cares that thread A races with thread B when logging.  It doesn't
matter that if A does something first and then B does its thing next
that B's log message appears first in the log.  What people do care
about is that A's log messages are written to the log in the order that
they occurred.  For example, if A performs tasks 1 and 2 then the log
message for 1 should be written before the log message for 2.  A
solution using the ThreadPool won't guarentee that because the
persisting of log messages can be dispatched to different threads.
Contrast that with my solution where log messages are dispatched to a
single thread.

A little code might help.

public class Logger
{
 private Thread thread;
 private BlockingQueue queue;

 public Logger()
 {
   queue = new BlockingQueue();
   thread = new Thread(this.ThreadMethod);
   thread.Start();
 }

 public void Log(string message)
 {
   queue.Enqueue(message);
 }

 private void ThreadMethod()
 {
   while (true)
   {
     string message = queue.Dequeue();
     // Persist the message to a file, database, etc.
   }
 }
}

Notice that since there is only one thread removing from the queue the
order that messages are received by the Logger is the order they are
persisted.  And it's impossible for any specific thread to queue its
messages out of order.

Brian