Delegates and Exceptions

[AC]

Hi All,

I have been experimenting with delegates and exceptions.
I know that when an exception occurs on a separate thread
it is saved and retrieved when EndInvoke is called, but
why can't I rethrow it?

Regards,

Example Code:

class Application
{
delegate void MyDelegate();

static void Main(string[] args)
{
Application app = new Application();
app.Start();

Console.ReadLine();
}
public void Start()
{
MyDelegate myDelegate = new MyDelegate(BadMethod);

myDelegate.BeginInvoke(new AsyncCallback
(DelegateCallback), myDelegate);
}
public void BadMethod()
{
string newstring = string.Empty;

if (newstring.Length == 0)
{
throw new ApplicationException("delegate
testing exception");
}
}
private void DelegateCallback(IAsyncResult ar)
{
MyDelegate result = (MyDelegate) ar.AsyncState;

try
{
result.EndInvoke(ar);
}
catch
{
throw;
}
}
}

[Jon Skeet [C# MVP]]

AC <an*******@discussions.microsoft.com> wrote:

I have been experimenting with delegates and exceptions.
I know that when an exception occurs on a separate thread
it is saved and retrieved when EndInvoke is called, but
why can't I rethrow it?

You can - what makes you think you can't?

Note that in your example, when your exception is rethrown, nothing is
reporting it because it's in a threadpool thread without any extra
exception handlers.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[AC]

Hi Jon,
Thanks for the reply. How would I catch exceptions
from the thread pool? I've tried registering a handler
for the AppDomain.UnhandledException to no avail.

Thanks

-----Original Message-----
AC <an*******@discussions.microsoft.com> wrote:

I have been experimenting with delegates and exceptions. I know that when an exception occurs on a separate thread it is saved and retrieved when EndInvoke is called, but why can't I rethrow it?
You can - what makes you think you can't?

Note that in your example, when your exception is

rethrown, nothing isreporting it because it's in a threadpool thread without any extraexception handlers.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

[David Levine]

"AC" <an*******@discussions.microsoft.com> wrote in message
news:11****************************@phx.gbl...

Hi Jon,
Thanks for the reply. How would I catch exceptions
from the thread pool? I've tried registering a handler
for the AppDomain.UnhandledException to no avail.

The threadpool itself catches and swallows all exceptions thrown on its
threads, so you will not get an unhandled exception. You need to catch all
the exceptions thrown in your threadpool callback routine and then
propagate that exception using your own mechanism. You can queue it up,
report it immediately, etc.

[AC]

Sorry I guess I'm being thick here. But that was what I
wanted to do in the first place. In the callback routine
I simple wanted to throw the exception so it gets
propagated up the call stack.

Would it be possible to point me at a simple example?

Thanks again.

-----Original Message-----

"AC" <an*******@discussions.microsoft.com> wrote in messagenews:11****************************@phx.gbl...

Hi Jon,
Thanks for the reply. How would I catch exceptions
from the thread pool? I've tried registering a handler
for the AppDomain.UnhandledException to no avail.
The threadpool itself catches and swallows all

exceptions thrown on itsthreads, so you will not get an unhandled exception. You need to catch allthe exceptions thrown in your threadpool callback routine and thenpropagate that exception using your own mechanism. You can queue it up,report it immediately, etc.
.

[Jon Skeet [C# MVP]]

AC <an*******@discussions.microsoft.com> wrote:

Sorry I guess I'm being thick here. But that was what I
wanted to do in the first place. In the callback routine
I simple wanted to throw the exception so it gets
propagated up the call stack.

Would it be possible to point me at a simple example?

Which thread's stack are you expecting it to get propagated up?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[DT]

I thought that because the callback executes on the main thread in my
example I could propagate the exception on that thread.

I guess my new question is how to detect exceptions in the threadpool?

Thanks again

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

AC <an*******@discussions.microsoft.com> wrote:

Sorry I guess I'm being thick here. But that was what I
wanted to do in the first place. In the callback routine
I simple wanted to throw the exception so it gets
propagated up the call stack.

Would it be possible to point me at a simple example?

Which thread's stack are you expecting it to get propagated up?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

DT <[e-mail]> wrote:

I thought that because the callback executes on the main thread in my
example I could propagate the exception on that thread.
No - the callback *doesn't* execute on the main thread. It can't,
because the main thread is busy doing something else by then - that's
the point of it being an asynchronous call in the first place.
I guess my new question is how to detect exceptions in the threadpool?

Well, you've got your callback - you can put whatever code you want in
there, including a big try/catch round whatever else is normally there.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[DT]

But the callback isn't the asynch process? Isn't the whole concept of a
callback to notify the caller that the asynch process has completed?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

DT <[e-mail]> wrote:

I thought that because the callback executes on the main thread in my
example I could propagate the exception on that thread.

No - the callback *doesn't* execute on the main thread. It can't,
because the main thread is busy doing something else by then - that's
the point of it being an asynchronous call in the first place.

I guess my new question is how to detect exceptions in the threadpool?

Well, you've got your callback - you can put whatever code you want in
there, including a big try/catch round whatever else is normally there.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

DT <[e-mail]> wrote:

But the callback isn't the asynch process? Isn't the whole concept of a
callback to notify the caller that the asynch process has completed?

No, it's to allow something to happen after the main async process has
completed. That "something" may involve the caller, but it may not.

Put it this way - after your call to BeginInvoke, the main thread goes
on its merry way and executes some more code. What would you expect the
stack trace to look like in the main thread when the callback was
invokved? Would you expect it to just interrupt the main thread
wherever it was? The nightmare of re-entrancy would be horrible in that
case.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[DT]

I didn't realise that. Thanks for your help

Regards

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

DT <[e-mail]> wrote:

But the callback isn't the asynch process? Isn't the whole concept of a
callback to notify the caller that the asynch process has completed?

No, it's to allow something to happen after the main async process has
completed. That "something" may involve the caller, but it may not.

Put it this way - after your call to BeginInvoke, the main thread goes
on its merry way and executes some more code. What would you expect the
stack trace to look like in the main thread when the callback was
invokved? Would you expect it to just interrupt the main thread
wherever it was? The nightmare of re-entrancy would be horrible in that
case.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[David Levine]

If you just want to capture the exception information you can do something
like this...wrap your callback with a try-catch and in the catch block
simply save the exception object into a queue; this executes in the context
of the threadpool thread. You can then set a flag or an event to notify the
main thread that new data is available and it can pull the exception object
out of the queue.

"DT" <[e-mail]> wrote in message
news:41**********************@mercury.nildram.net. ..

I didn't realise that. Thanks for your help

Regards

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

DT <[e-mail]> wrote:

But the callback isn't the asynch process? Isn't the whole concept of a
callback to notify the caller that the asynch process has completed?

No, it's to allow something to happen after the main async process has
completed. That "something" may involve the caller, but it may not.

Put it this way - after your call to BeginInvoke, the main thread goes
on its merry way and executes some more code. What would you expect the
stack trace to look like in the main thread when the callback was
invokved? Would you expect it to just interrupt the main thread
wherever it was? The nightmare of re-entrancy would be horrible in that
case.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[DT]

Thanks David

"David Levine" <no******************@wi.rr.com> wrote in message
news:ua**************@TK2MSFTNGP12.phx.gbl...

If you just want to capture the exception information you can do something
like this...wrap your callback with a try-catch and in the catch block
simply save the exception object into a queue; this executes in the
context of the threadpool thread. You can then set a flag or an event to
notify the main thread that new data is available and it can pull the
exception object out of the queue.

"DT" <[e-mail]> wrote in message
news:41**********************@mercury.nildram.net. ..

I didn't realise that. Thanks for your help

Regards

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

DT <[e-mail]> wrote:
But the callback isn't the asynch process? Isn't the whole concept of
a
callback to notify the caller that the asynch process has completed?

No, it's to allow something to happen after the main async process has
completed. That "something" may involve the caller, but it may not.

Put it this way - after your call to BeginInvoke, the main thread goes
on its merry way and executes some more code. What would you expect the
stack trace to look like in the main thread when the callback was
invokved? Would you expect it to just interrupt the main thread
wherever it was? The nightmare of re-entrancy would be horrible in that
case.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too