As with any program, you can use some common methods, no matter what type of environment you are in. The most basic of these involves logging all your debugging information to a file that can be reviewed later. Because the Web Service has very little interaction with the user interface, this is one approach to take. The other approach is to build your own exception class that you can customize. Then, whenever an error occurs ,you can throw your custom exception.
You might encounter this common error:
The underlying connection was closed: Unable to connect to the remote server."
This is typically the result of problems on the network, not necessarily in your code. But don’t rule out your code—have someone else look at it to see if you have overlooked something. A second pair of eyes is always beneficial.
Another error is the SoapException error, which looks like this:
The request reached the server machine, but was not processed successfully.
If you run into this one, you might be wondering, what wasn’t processed successfully? Why didn’t it tell me what wasn’t processed? If you are using the standard exception class to handle errors, you could be missing out on some important information provide by the SoapException class. Let’s take a closer look at this class in the next section.
Up to this point, you have looked at various problems that might arise and learned how to work around them. But one of the key elements of debugging Web Services is the SoapException class. Not only does the class handle exceptions that were thrown, but, within the properties of the exception, there are some very useful pieces of data that can help to identify what the problem is.
Take a look at Listings 13 .28 and 13.29 to see how you can use the SoapException class to catch errors.
private void Button2_Click(object sender, System.EventArgs e) { try { localhost.Service1 s = new localhost.Service1(); s.HelloWorld(2);//This will throw an exception } catch(SoapException ex) { //Display the main message TextBox2. Text = ex.Message; //Get any additional detailed information System.Xml.XmlNode xn = ex.Detail; //How many Attributes are there TextBox3. Text = xn.Attributes.Count. ToString(); //The name of the app or object that caused the problem TextBox4. Text = ex.Source; //Display the piece of code that caused the problem TextBox5. Text = ex.Actor; //Get the type of SOAP fault code System.Xml.XmlQualifiedName qn = ex.Code; //Get the XML qualified name TextBox6. Text = qn.Name; //Get the XML namespace TextBox7. Text = qn.Namespace; //Get the method that throws the exception System.Reflection.MethodBase r = ex. TargetSite; System. Type st = r.DeclaringType; //Get the assembly name where the exception came from TextBox8. Text = st.AssemblyQualifiedName; } } |
Private Sub Button2_Click(ByVal sender As Object, ByVal e As System.EventArgs) Try localhost.Service1(s = New localhost.Service1()) s.HelloWorld(2) 'This will throw an exception catch(SoapException ex) 'Display the main message TextBox2. Text = ex.Message 'Get any additional detailed information System.Xml.XmlNode(xn = ex.Detail) 'How many Attributes are there TextBox3. Text = xn.Attributes.Count. ToString() The name of the app or object that caused the problem TextBox4. Text = ex.Source 'Display the piece of code that caused the problem TextBox5. Text = ex.Actor 'Get the type of SOAP fault code Dim qn As System.Xml.XmlQualifiedName qn = ex.Code 'Get the XML qualified name TextBox6. Text = qn.Name 'Get the XML namespace TextBox7. Text = qn.Namespace 'Get the method that throws the exception Dim r As System.Reflection.MethodBase r = ex. TargetSite Dim st As System. Type st = r.DeclaringType 'Get the assembly name where the exection came from TextBox8. Text = st .AssemblyQualifiedName End Try End Sub |
Listings 13.28 and 13.29 demonstrate how to extract the additional elements that are part of the SoapException class. These additional properties could help you identify the problem, either directly or indirectly.