Debuging EventTopicExceptions

Topics: CAB & Smart Client Software Factory
Mar 4, 2006 at 1:39 PM
originally posted by: samkuehn

When I have a method that subscribes to and Event/StateChanged and that method throws an exception I get back an EventTopicException informing me what event fired caused the exception but I am having a difficult time tracking do the offending method. I have some events that are subscribed to by 20 methods or so. This makes debugging very difficult. Do you have any hints, tips or tricks for doing debugging. Is there a way to wrap these method body in a try/catch block where the debugger will inside the actual method? Is there some place that I cannot find in the exception that will give me the information? I have been wasting a lot of time tracking down uncaught null reference exceptions and such.

Thanks guys!
Mar 29, 2006 at 2:16 AM
originally posted by: DingDongLars

Hi

This post has been on the thread for a while. As I am also very interested in a reply I post this to if somebody reacts :-)

Sorry Sam, I hope you are not too disappointed that this is not the reply you are waiting for

Lars
Mar 29, 2006 at 4:13 AM
originally posted by: DLorenz

Try
..
Catch ex As Microsoft.Practices.CompositeUI.EventBroker.EventTopicException
Dim msgs As String = String.Empty
For Each msg As Exception In ex.Exceptions
msgs &= msg.Message & Environment.NewLine
Next
Dim temp As Exception = ex
msgs &= Environment.NewLine
While temp IsNot Nothing
msgs &= ex.Message & Environment.NewLine
temp = ex.InnerException
End While
msgs &= Environment.NewLine
For Each msg As Exception In ex.Exceptions
msgs &= msg.ToString & Environment.NewLine
Next
MessageBox.Show(msgs)
Catch ex As Exception
Dim msgs As String = String.Empty
Dim temp As Exception = ex
While temp IsNot Nothing
msgs &= ex.Message & Environment.NewLine
temp = ex.InnerException
End While
MessageBox.Show(msgs)
End Try

Hope this helps.
Mar 29, 2006 at 4:45 AM
originally posted by: DingDongLars

That really helps. I never noticed the Exceptions collection, thanks.

Here's a follow up, tho.

I am a newbie to CAB but have managed to develop a nice CAB application to much applause from my team (with no knowledge of CAB or even .NET :-) ). Now I am trying to get some kind of grip on the logging of exceptions thru the Enterprise Library.

In the Appraisal WorkBench from the SC-BAT the EL is utilized and the Default Policy is responsible for the last resort logging of unhandled exceptions implemented in the ShellApplication.cs HandleException method.

Now, the TextExceptionFormatter applied by the EL Default Policy doesn't know about the Exceptions collection on the Microsoft.Practices.CompositeUI.EventBroker.EventTopicException, so these never get logged anywhere.

I wonder what the correct approach to ensure logging of the interesting exceptions in the collection would be?

1. Specifically handling EventTopicExceptions in the global HandleException method. Seems to me to a very detailed thing to put at this very global level.

2. Writing a custom exception formatter for EL. Bit of the same thing, really. Maybe using reflection to sniff out if the Exceptions collection is present would help make such a thing more generic, but...

3. Waiting for the CAB folks and the EL folks to come up with THE solution. Yes!

4. Receiving an answer to this post informing me of the perfect solution already implemented by the CAB folks and the EL folks. The best!

Thanks
Lars
Mar 29, 2006 at 4:50 AM
originally posted by: DLorenz

Well, when our application finally gets around to getting the Exception handling added in, I think I'm going to go into the CAB framework and make those Exceptions be added on as Inner Exceptions as well. I honestly don't know why Microsoft decided to make the exceptions work like that.
Mar 29, 2006 at 5:06 AM
originally posted by: DingDongLars

Given the nature of the event broker pattern, I can see the problem. It seems to me that the EventTopicException is a bucket to contain all exceptions thrown by the subscribing handlers. As this is a flat list and not the usual hierarky of inner exceptions the Exceptions collection makes good sense to me. I mean, when you pointed out the exceptions collection to me, I had a distinct 'AHA' experience.

But nevertheless it seems like a bit of a black sheep in the context of exceptions, especially when considering the generic handling of the unhandled ones at the end of the line.

Would be very interesting to hear some comments from the CAB team on this