Exception Handling Question

[Chuck Cobb]

I'm implementing a centralized exception handling routine using the
Enterprise Library Exception Management Application Block.

I trap all unhandled exceptions to one place using the following method:

// --- Create an Exception Handler for Thread Exceptions ----------------

Application.Thr eadException += new
ThreadException EventHandler(On ThreadException );

// --- Create an Exception Handler for Unhandled Exceptions -------------

AppDomain currentDomain = AppDomain.Curre ntDomain;

currentDomain.U nhandledExcepti on += new
UnhandledExcept ionEventHandler (OnUnhandledExc eption);

private static void OnThreadExcepti on(object sender,

ThreadException EventArgs t)

//
*************** *************** *************** *************** *************** ***

// Handles Normal Thread Exceptions

//
*************** *************** *************** *************** *************** ***

{

Exceptions.LogA ndReportError(t .Exception);

}

private static void OnUnhandledExce ption(object sender,

UnhandledExcept ionEventArgs args)

//
*************** *************** *************** *************** *************** ***

// Handles All Unhandled Exceptions

//
*************** *************** *************** *************** *************** ***

{

Exceptions.LogA ndReportError(a rgs.ExceptionOb ject as System.Exceptio n);

}

The problem I have is that exceptions that occur on a background thread are
not being picked up. If I do a "throw" on an exception in a background
thread it has no place to go and just disappears as an unhandled exception.
How can I pick up these exceptions without handling them in the background
thread?

Thanks,

Chuck Cobb

[Chuck Cobb]

Thanks...
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:OP******** ******@TK2MSFTN GP04.phx.gbl...

"Chuck Cobb" <ch********@oxf ordcorp.com> wrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
| Thanks for posting this code I tried it out and the primary difference
| between your code and my code is how it starts an auxiliary thread:
|
| Your code:
| new Thread(delegate ()
|
| {
|
| ThrowExceptionI nsideTryCatch() ;
|
| }).Start();
|
| My Code:
|
| MethodInvoker mi = new
MethodInvoker(T hrowExceptionOu tsideTryCatch);
|
| mi.BeginInvoke( null, null);
|

This doesn't start a auxiliary thread, it delegates the
ThrowExceptionO utsideTryCatch function to execute on the 'UI thread', but
as
you call this from the UI thread, it simply boils down into a simple call
to
ThrowExceptionO utsideTryCatch.

Willy.

[Christoph Nahr]

Thanks. First, I could indeed reproduce the problem.

But as Willy already said, just calling some variant of Invoke usually
doesn't start a background thread at all -- it merely performs an
invocation on the current thread, same as just writing out the method
call. That's true even for BeginInvoke/EndInvoke (on the Control
class) which only perform cross-thread marshalling if needed.

Nevertheless, the UnhandledExcept ion handler should be triggered. But
this is apparently one of the undocumented features of the
undocumented MethodInvoker.B eginInvoke method that you were using. How
do you know it's undocumented and should not be used? Because this
method does not appear in the MSDN docs, and its IntelliSense display
does not show any description other than the prototype.

In fact, MethodInvoker offers only a single "official" invocation
method, and that's DynamicInvoke (inherited from its base class
Delegate). And when I used that documented method the
UnhandledExcept ion handler was properly triggered -- for either
ThrowException. .. method, whichever is executed first.

Moral: Don't use undocumented .NET Framework methods! Actually, don't
use MethodInvoker at all. It's just a simple delegate, and the three
methods it offers in addition to Delegate/MulticastDelega te are all
intended for internal Windows.Forms use only. The class should never
have been publically exposed in the first place IMO.
--
http://www.kynosarges.de

[Willy Denoyette [MVP]]

Christoph,

See inline..

Willy.

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:1u******** *************** *********@4ax.c om...
| Thanks. First, I could indeed reproduce the problem.
|
| But as Willy already said, just calling some variant of Invoke usually
| doesn't start a background thread at all -- it merely performs an
| invocation on the current thread, same as just writing out the method
| call. That's true even for BeginInvoke/EndInvoke (on the Control
| class) which only perform cross-thread marshalling if needed.
|
| Nevertheless, the UnhandledExcept ion handler should be triggered.

No it should not, the exception is thrown on the UI thead, so the
ThreadException handler is invoked.
UnhandledExcept ion handlers are only invoked when "unhandled" exceptions are
originating from non UI threads.
But
| this is apparently one of the undocumented features of the
| undocumented MethodInvoker.B eginInvoke method that you were using. How
| do you know it's undocumented and should not be used? Because this
| method does not appear in the MSDN docs, and its IntelliSense display
| does not show any description other than the prototype.
|
| In fact, MethodInvoker offers only a single "official" invocation
| method, and that's DynamicInvoke (inherited from its base class
| Delegate). And when I used that documented method the
| UnhandledExcept ion handler was properly triggered -- for either
| ThrowException. .. method, whichever is executed first.
|
| Moral: Don't use undocumented .NET Framework methods! Actually, don't
| use MethodInvoker at all. It's just a simple delegate, and the three
| methods it offers in addition to Delegate/MulticastDelega te are all
| intended for internal Windows.Forms use only. The class should never
| have been publically exposed in the first place IMO.
| --
| http://www.kynosarges.de

[Christoph Nahr]

On Sat, 22 Apr 2006 11:23:45 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:

No it should not, the exception is thrown on the UI thead, so the
ThreadExceptio n handler is invoked.
UnhandledExcep tion handlers are only invoked when "unhandled" exceptions are
originating from non UI threads.

Willy, haven't you read the rest of my post? The UnhandledExcept ion
handler *was* triggered when BeginInvoke was changed to DynamicInvoke,
or when the exception methods were called directly. The
ThreadException handler *was not* triggered.

As to why, I'm not sure. In the test program the exception is thrown
before a form is even constructed, so technically there is no GUI
(Windows Forms) thread at the time of the exception. Remember that
ThreadException is a Windows Forms feature, not a general threading
feature. Possibly it requires a window event queue to work.
--
http://www.kynosarges.de

[Christoph Nahr]

Oh dear, oh dear. Attention: I'm a dumbass. Willy is also a dumbass.
Chuck is very smart and was actually mostly right. Should have read
the chapter on asynchronous operations in Jeff Richter's "CLR via C#"
before replying. I'm very sorry... here comes the correct version.

I got completely sidetracked by reminiscences of Control.BeginIn voke
which does not start a new thread. But in fact, the MethodInvoker
methods Invoke/BeginInvoke/EndInvoke are undocumented because they're
*auto-generated* for each delegate class. The BeginInvoke method is
proper to call and does, in fact, start a new background thread.

I no longer understand why the MSDN docs say that MethodInvoker.I nvoke
is "for internal use" only; that does not seem to make sense. All of
these methods should be proper for anyone's use.

Okay. So why didn't UnhandledExcept ion get called? That's because
the auto-generated BeginInvoke method of a delegate executes on a
thread in the CLR thread pool, and any exceptions thrown by a thread
pool thread are automatically swallowed by the CLR until the
corresponding EndInvoke is called, at which point they're thrown.

So Chuck should see his UnhandledExcept ion handler activated when the
BeginInvoke call is paired with an EndInvoke call.

All this is explained in Jeff Richter's "CLR via C#", chapter 23,
pages 614f. Ironically, it's the book I tell everyone to read... that
was the last chapter I had not gotten around to read until now.
--
http://www.kynosarges.de

[Christoph Nahr]

On Sat, 22 Apr 2006 14:10:20 +0200, Christoph Nahr
<ch************ @kynosarges.de> wrote:

I no longer understand why the MSDN docs say that MethodInvoker.I nvoke
is "for internal use" only; that does not seem to make sense. All of
these methods should be proper for anyone's use.

Jesus, what's wrong with me? The MSDN docs don't say that at all,
that was some other method I was looking up. Scratch that paragraph.
--
http://www.kynosarges.de

[Willy Denoyette [MVP]]

Well, actually I didn't pay attention to the BeginIvoke call (I even didn't
look at the attached code), I only noticed the MethodInvoker, which was
enough to conclude that the exception was not thrown on an "auxiliary"
thread (but being a dumbass, I wrongly assumed that it was on the UI
thread). Notice that I call an "auxiliary thread", a thread that is
explicitly created via a call to a Thread class constructor. Only unhandled
exceptions originating from "auxiliary" threads are routed to the
UnhandledExcept ion handler, 'unhandled' exceptions originating from pool
threads are not, they have to be handled explicitly, as you correctly
mentioned. Note that every BeginInvoke on a delegate has to be paired with
an EndInvoke call, this is mandatory on the CLR, failing to do this may
result in handle leaks.

Willy.

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:hr******** *************** *********@4ax.c om...
| Oh dear, oh dear. Attention: I'm a dumbass. Willy is also a dumbass.
| Chuck is very smart and was actually mostly right. Should have read
| the chapter on asynchronous operations in Jeff Richter's "CLR via C#"
| before replying. I'm very sorry... here comes the correct version.
|
| I got completely sidetracked by reminiscences of Control.BeginIn voke
| which does not start a new thread. But in fact, the MethodInvoker
| methods Invoke/BeginInvoke/EndInvoke are undocumented because they're
| *auto-generated* for each delegate class. The BeginInvoke method is
| proper to call and does, in fact, start a new background thread.
|
| I no longer understand why the MSDN docs say that MethodInvoker.I nvoke
| is "for internal use" only; that does not seem to make sense. All of
| these methods should be proper for anyone's use.
|
| Okay. So why didn't UnhandledExcept ion get called? That's because
| the auto-generated BeginInvoke method of a delegate executes on a
| thread in the CLR thread pool, and any exceptions thrown by a thread
| pool thread are automatically swallowed by the CLR until the
| corresponding EndInvoke is called, at which point they're thrown.
|
| So Chuck should see his UnhandledExcept ion handler activated when the
| BeginInvoke call is paired with an EndInvoke call.
|
| All this is explained in Jeff Richter's "CLR via C#", chapter 23,
| pages 614f. Ironically, it's the book I tell everyone to read... that
| was the last chapter I had not gotten around to read until now.
| --
| http://www.kynosarges.de