Friday, September 4, 2009

SyncComm 0.95 Exception Handling

Despite the delay of the last SyncComm’s version it has finally  been released. There are important improvements which I have been working on during the last months. One of such improvements is the enhancement of exception handling between the WCF component and the client’s generated proxy.

By default, when an exception occurs on the WCF Service the client proxy does not entirely deserialize the fault message received. Thus, when the exception is caught by the caller method the exception message thrown by the WCF Service is not available although the message has been sent and received. Just not right.

To solve this issue some changes have had to be made on CFClientBase class, especially on processReply method. If you wish to get further information about how it works, see WCF Guidance for Mobile Developers, section Error Handling.

Throwing exceptions from WCF SyncComm components

Each ServiceContract implementation has its own try..catch statement and all those methods throw the exception in the same way. Basically, “an exception” contains:

  • Exception/InnerException message
  • Fault reason text (‘friendly’ message)
  • Fault code
    • An universal identifier
    • WCF namespace

Check the following code extracted from SyncComm.Service.SyncService class’s constructor.

catch (SqlException sqlex)
Guid id = Guid.NewGuid();

//display detailed exception information on console
string.Format ("Exception {0}: {1}", id.ToString(), sqlex.Message));

//throw and exception for being catch by client
throw new FaultException<string>(sqlex.Message, new FaultReason(
new FaultReasonText("SQL Server is not available. Please try later.")),
FaultCode.CreateSenderFaultCode(id.ToString(), ""));

catch (Exception e)
Guid id = Guid.NewGuid();

//display detailed exception information on console
string.Format ("Exception {0}: {1}",id.ToString(),e.Message));

throw new FaultException<string>(e.Message, new FaultReason(
new FaultReasonText("SyncService unavailable. Contact SyncService support.")),
FaultCode.CreateSenderFaultCode(id.ToString(), ""));


As you could appreciate, there are some issues you may pay attention on. At first, throwing the entire exception message is not a good practice because the exception message could contain sensitive information. On the other hand, the error message should head the user to perform any action he might do to solve it, hence, despite the WCF SyncService is not available due to technical reason, for example, SQL Server is not available because it is being restarted for maintenance purposes , which solutions is trivial, the friendly message that might be thrown should be:

“SyncService unavailable. Contact SyncService support or try again later.”

Instead of:

“… The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured…”

This kind of message personalization is possible right now by SyncComm.

Exception’s unique identifier represented by System.Guid object should be useful for identifying such exception on both sides. For example, consider the next exception thrown on server side:


FaultException message is sent to client whilst FaultException is shown on ServiceHost console application:


Handling exceptions by SyncComm client

The SyncAgent’s Sync() method’s call is wrapped by try…catch statement. After a call of the method any exception will be caught by one of the following Exception types:

  • CFFaultSyncException which catches all application’s exceptions thrown by WCF Service.

  • CommunicationException which catches any communication error in either client or server side.

  • Exception which catches any other non-typed exception, for example channel’s timeout expiring.

Let’s talk about CFFaultSyncException type case. This exception type returns a bunch of information about exception caught and thrown by WCF Service. The most important thing is that inside this object we have a couple of description fields of the source exception. Recall the structure of FaultException explained above. There is a friendly message as well as more technical one. The friendly message is the one you should drop onto application screen whilst technical one is such you should log to be checked later. Remember, entire exception has a unique identifier that corresponds with FaultException thrown by server.

Here you are an example showed above, about how it is handled by client:


At the result, friendly message is dropped:


Whilst a more detailed exception’s message is properly logged.

The code of the client would be something like:

catch (CFFaultSyncException faultEx)
Cursor.Current = Cursors.Default;

MessageBox.Show(string.Format("FaultCode: {0}\r\nFaultReason: {1}\r\nHasDetail: {2}",
faultEx.FaultCode, faultEx.FaultMessage, faultEx.HasDetail));
catch (CommunicationException communicationException )
//is the emulator cradled? does it reach SyncService endpoint?
catch (Exception e)
//something is not configured properly
//HResult -2146233087 maybe database must be reinitialize


Any doubt or comment? please contact here.


No comments: