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
Notification.Invoke(DateTime.Now,
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(), "urn:synccomm.com/2009/07/ISyncService"));
}
catch (Exception e)
{
Guid id = Guid.NewGuid();
//display detailed exception information on console
Notification.Invoke(DateTime.Now,
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(), "urn:synccomm.com/2009/07/ISyncService"));
}
“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?
MessageBox.Show(communicationException.Message);
}
catch (Exception e)
{
//something is not configured properly
MessageBox.Show(e.Message);
//HResult -2146233087 maybe database must be reinitialize
}
Any doubt or comment? please contact here.
Cheers,
