Stephen Cave, Rafael Zuniga
Summary:
The purpose of this lab is to demonstrate how you can declare fault contracts, throw faults, and trap faults.
Procedure
We start by opening up the provided Visual Studio solution found in the Chapter8/FaultContract/ of our labs directory. It opens up and compiles fine as you can see below:
Attempting to run the server we find the following error:
Following the link gives a solution involving registering our URL as a privileged since we're using Windows 7 which, like Vista, does not run everything with administrator privileges. Instead of registering the host we instead run it with administrator privileges. This time we have the host running successfully and can attempt to upload an image which results in:

An exception message that doesn't really tell us much. Next we modify the code in PhotoManagerService.cs to throw a fault exception instead by adding the following to the UploadPhoto method:
try {
PhotoUploadUtil photoUploadUtil = new PhotoUploadUtil();
photoUploadUtil.SavePhoto(fileInfo, fileData);
} catch (ConfigurationErrorsException exConfig) { throw new FaultException(exConfig.Message); }
We compile again, run it, and this time we see the following e:

Which is much more descriptive and helps us in figuring out what's gone wrong. Next we add an attribute to the UploadPhoto method declaration within the IPhotoUpload interface. This will allow us to throw a strongly typed exception when a fault occurs which is useful if you'd like to use custom exception classes. To continue we need to modify our previous exception catching code:
catch (ConfigurationErrorsException exConfig)
{
throw new FaultException
}
We also modify the client side proxy to support the new exception contract by adding an identical fault contract attribute to the existing code which can be found in localhost.cs and adding an assembly reference to the client project. Now the client must be modified to actually catch the exception:
catch(FaultException
{
string s = String.Format("{0}\r\nERROR:(1)",
exConfig.GetType(), exConfig.Detail.Message);
MessageBox.Show(s);
}
We recompile and now see our strongly typed fault exception:

Observations:
- Windows 7 is pretty neat but the UAC options can really throw you for a loop if you're used to everything running as an administrator
- The default settings in for the TCP transport cause it to choke on larger images
- Being able to give a user a better error than the cryptic "ERROR: -14" is always a good thing
- I'm surprised that the error in the first screen shot also gave me a link on how to resolve it
No comments:
Post a Comment