Exceptions vs. Events

[Wavemaker]

I have a class written in C# which uses a worker thread
internally to do some processing. It's possible that an
exceptional situation can arise in the worker thread, and as
the class is presently written, it throws an exception in
those cases.

But I don't think this is a good design. I don't see how
these exceptions can be caught. Plus, exiting a thread by
throwing an exception probably isn't very clean either.

So I was thinking about using events instead. When an
exceptional situation arises in the worker thread, have it
raise an event letting clients know about the problem.

The XmlValidatingReader class use an ValidationEventHandler
for passing exceptions through events, so there is a
precedence for this approach.

Anyway, I'd appreciate advice. Thanks.

[Jon Skeet [C# MVP]]

Wavemaker <ja**********@BiteMeHotmail.com> wrote:

I have a class written in C# which uses a worker thread
internally to do some processing. It's possible that an
exceptional situation can arise in the worker thread, and as
the class is presently written, it throws an exception in
those cases.

But I don't think this is a good design. I don't see how
these exceptions can be caught. Plus, exiting a thread by
throwing an exception probably isn't very clean either.

So I was thinking about using events instead. When an
exceptional situation arises in the worker thread, have it
raise an event letting clients know about the problem.

The XmlValidatingReader class use an ValidationEventHandler
for passing exceptions through events, so there is a
precedence for this approach.

Anyway, I'd appreciate advice. Thanks.

If you want to use a custom threadpool for this, mine happens to do
exactly what you want :)

See http://www.pobox.com/~skeet/csharp/miscutil and look at the
CustomThreadPool class.

Of course, there's always AppDomain.UnhandledException, too.

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

[Stephen Lamb]

"Wavemaker" <ja**********@BiteMeHotmail.com> wrote in message
news:lO********************@comcast.com...

I have a class written in C# which uses a worker thread
internally to do some processing. It's possible that an
exceptional situation can arise in the worker thread, and as
the class is presently written, it throws an exception in
those cases.

But I don't think this is a good design. I don't see how
these exceptions can be caught. Plus, exiting a thread by
throwing an exception probably isn't very clean either.
This approach relies on implementation defined behavrior.

From the C# Language Specification, ECMA-334 2nd edition - December 2002,
section 23.3 which talks about how exceptions are handled.

"If the search for matching catch clauses reaches the code that initially
started the thread, then execution
of the thread is terminated. The impact of such termination is
implementation-defined."
So I was thinking about using events instead. When an
exceptional situation arises in the worker thread, have it
raise an event letting clients know about the problem.
Care must be taken in this approach to prevent deadlock if the controlling
thread ever blocks waiting for the worker thread.
The XmlValidatingReader class use an ValidationEventHandler
for passing exceptions through events, so there is a
precedence for this approach.

Anyway, I'd appreciate advice. Thanks.

I use the same approach, raise an event in the worker thread when an
exception is thrown. I do something like the following

void ThreadMethod()
{
try
{
ActuallyDoThreadStuff();
}
catch (ThreadAbortException e)
{
// Ignore exception since shutting down isn't considered an error.
}
catch (Exception e)
{
RaiseExceptionEvent(e);
}
}