Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Error Handling and Diagnostic in Eneter.Messaging.Framework

, 16 Aug 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
The article describes the error handling behavior of Eneter.Messaging.Framework and shows how to use Debug View for the diagnostic.

Summary

The article describes the error handling behavior of Eneter.Messaging.Framework and shows how to use Debug View for the diagnostic.

Introduction for Newcomers

If you are new, then Eneter.Messaging.Framework is a middleware that allows to implement the communication between applications based on messages. The framework supports NamedPipes, TCP, HTTP and also Silverlight Messaging.

For more technical details, you can refer to my previous articles or you can visit http://www.eneter.net/OnlineHelp/EneterMessagingFramework/Index.html.
(The framework is free and can be downloaded from www.eneter.net.)

Error Handling Behavior

The error handling in Eneter.Messaging.Framework is based on 4 main scenarios:

  1. The error occurs in the framework when the user invokes some API method.

    This scenario occurs when the user calls the framework API and the call fails.
    E.g. The SendMessage() method is called, but the output channel is not attached. Or when you create the channel and the channel id is not the valid URI address (in case of Named Pipe, TCP or HTTP).

    In this case, the framework logs the error to the debug port and throws an exception (ArgumentException, ArgumentNullException, InvalidOperationException or a communication technology specific exception).
    The exception can be caught in the user code and processed.

  2. The error occurs in the user code when it is invoked from the framework as a callback.

    This scenario typically occurs when the framework calls an event handler (or a callback) provided by the user and this handler throws an exception.
    E.g. The framework calls the user code subscribed to the event MessageReceived and the user code throws some exception.

    In this case, the framework catches all exceptions and logs them to the debug port.
    (In spite of the fact, the framework handles these exceptions, it is recommended that exceptions from event handlers and callbacks are not propagated to the framework. Better, the user code should catch them.)

  3. The error occurs in the framework code while processing a received message.

    This scenario occurs when the framework receives a message from a sender and detects a problem during processing of the message.
    E.g. The deserialization of the received message failed.

    In this case, the framework logs the error to the debug port and notifies the error to the user code in the MessageReceived event. The event has the property public Exception ReceivingError {get;}.
    The user code should evaluate this property when it processes a received message.

  4. The error occurs in a framework component in runtime.

    This scenario normally should not occur. But if the framework detects some error that cannot be reported to the user code via exception or event, the framework logs the error to the debug port, from where it can be read by a programmer.

Diagnostic

As described above, whenever the framework detects an error, it uses the debug port to announce the issue. Except errors, the framework also recognizes potential problems and announces them to the debug port as warning messages.
Therefore, to diagnose the communication, you can use a debug port viewer. E.g. You can download one from Microsoft.

To recognize messages in the debug port more effectively, you can setup the filter and colors. E.g. Errors can be red and warnings yellow. The framework labels errors as ' E:' and warnings as ' W:'.

DebugViewFilterSetting.jpg

And here is the example of the output for Eneter.Messaging.Framework.

I hope you enjoyed the article.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Ondrej_Uzovic
Architect
Slovakia Slovakia
My programming path started in 1987 when I got my first computer Sharp MZ-800.
It came with 8 bit CPU Z80, 64Kb RAM and the tape recorder. It was a great machine. I think I still have it somewhere.
I was fascinated and I started to write first programs. Eventually I became developer and software architect. I like innovations and clean nice solutions.

Comments and Discussions

 
GeneralMy vote of 4 PinmemberPranay Rana17-Aug-10 3:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.141015.1 | Last Updated 16 Aug 2010
Article Copyright 2010 by Ondrej_Uzovic
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid