eneter.net: Error Handling and Diagnostic in Eneter.Messaging.Framework

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.
(Full, not limited and for non-commercial usage free version of the framework 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 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 log them to the debug port.
(In spite of the fact, the framework handles these exceptions, it is recomended 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 during 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 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.
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

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:'.