Delegates and Events vs. Exception bubbling

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I am considering using an internal system that handles exceptions by calling
an event. Would this be of any benefit or not in terms of performance ?
This is a serviced component that uses txns using the AutoComplete attribute.

After trying to solve the problem in the catch clause, I want to notify the
client of the exception .

Thanks in advance

Garret
 
Garnet2 said:
Hello,

I am considering using an internal system that handles exceptions by
calling
an event. Would this be of any benefit or not in terms of performance ?
Click to expand...

Performance relative to what alternative?
This is a serviced component that uses txns using the AutoComplete
attribute.

After trying to solve the problem in the catch clause, I want to notify
the
client of the exception .
Click to expand...

Why not just let the exception propagate to the client if you weren't able
to handle it in the component?

John Saunders
 
I agrea with letting the exception carry on to the client, but when looking
at the performance figures when throwing exception - there seems to be a
pretty big performance penalty for doing this.

This only confirmed what many of the .net practices suggest on how to write
efficient code.

So I though I could implement an internal id (GetHashCode()) system to track
the items as they flow through the system and then create my own type that
holds the exception info and pass it back through an event that the client
would subscribe to using a public delegate.

I was hoping this help me gain some performance as I am already using COM+
as well as MSMQ and want to avoid any more performance hits where possible.

I just wanted to know if anyone knew about passing objects via events, in
contrast to essentially doing the same thing via exception handling from a
performace perspective.

Thanks in advance
 
But the exception has already been thrown in your proposed design. Doing an
event to pass this back to the caller would surely be worse (you have to
create the event args object for a start). Secondly the client now has to
deal with exception in 2 differnt ways - many will come via the normal
mechanism (system code throwing) and now some will come via Events.

Too much is made of exceptions being expensive. They are by definition
exceptional, i.e they happen infrequently (unless of course you use then as a
way of exiting while loops etc - please no) so they should have no noticable
hit.

Your design would be extremely interesting however for some debugging /
monitoing tool that is not in the call chain but would like to track
exceptions. It is a major omission in the CLR that you cannot do this as
standard. It allows you to hook unhandled exceptions but not thrown
exceptions - there is an excellent example of how to do it from outside the
CLR using the profiling API in the "debugging .NET applications" boo" - v
good book BTW.
 
Hi,
I just wanted to know if anyone knew about passing objects via events, in
contrast to essentially doing the same thing via exception handling from a
performace perspective.
Click to expand...

Here a benchmark from an outproc activated managed ServiceComponent:

Throwing 1000 exceptions: 19 secs
Raising 1000 COM+ transient events: 29 secs

The events were empty calls: I omited to pass any information back.
Not to compare with the rich exception object.

Since COM+ events are really a pain to implement, I simply
don't unterstand how you came up with that idea :-)

bye
Rob
 
Thanks Robert,

The results comparing exceptions and events was what I was looking for.
Based on past comments that performance with relation to exceptions is
exagerated made by pmoor has also influenced my decision and will implement
the exceptions through exception handling. (because while there is quite a
bit of exception code that can be executed, they are exceptions and the
system should avoid those situations from occuring - if possible)

Thank you, much appreciated.
 
Back
Top