Handling and Throwing Exceptions in Web Services
Handling and Throwing Exceptions in Web Services Exception handling between Web Services and clients uses the same mechanics as exception handling in Windows Forms, for example. You can use a Try...Catch...End Try block to catch any exception within the Web Service. However, if you propagate, or allow an exception to be propagated, across a Web Service boundary, the exception is serialized as an XML <Fault>. When it gets to your client application, it arrives as a SoapException or SoapHeaderException. For example, if we did not catch a DivideByZeroException on line 73 of Listing 18.6, a DivideByZeroException would occur in the Web Service, but ASP.NET would propagate this as a SoapException in the client application. To catch an exception raised by an ASP.NET Web Service, you can write a generic exception handler or catch one of the two SOAP exceptions. Try ' Some Web Service Code Catch ' Do something to recover End Try or Try ' Some Web Service Code Catch x As SoapException ' Do Something to recover End Try Either version would allow you to catch a Web Service exception in the client application. However, if you wrote a specific exception handler to catch the DivideByZeroException thrown by the scenario described at the beginning of this section, the Catch block would not catch the exception because your Catch block would contain the wrong type. The SoapException.Message property will contain the text of the original exception. Figure 18.10 shows the Message value of a DivideByZeroException originating in the Dice Web Service as received by an ASP.NET Web application. Figure 18.10. An exception thrown in a Web Service is serialized and sent to a client as a SoapException, as shown. |
 | |
Team-Fly  |
| Top |
