This post originated from an RSS feed registered with .NET Buzz
by James Avery.
Original Post: SOA, Web Services, and Exceptions
Feed Title: .Avery Blog
Feed URL: /blog/Install/BlogNotConfiguredError.aspx
Feed Description: .NET and everything nice
Not really. When you look at dealing with exceptions across a web service you have to keep the primary goal of web services in mind, which is enabling loosely coupled systems. Keeping this primary goal in mind means that we need to throw an exception that is XML and its probably a good idea to be at least partly human readable (I would want to include a message AND an ID, not just an ID), the SOAP specification handles this with the SOAP Fault.
.NET accommodates the SOAP fault with the SoapException which creates a SOAP fault (<fault> element) automatically for you based on the .NET exception that you threw inside your application. You can also create a SoapException on your own and use the detail element to add any sort of extra information to the SoapException, this is where you can put your exception code or other special information about your exception. (You could even serialize your exception using binary serialization and stick it in the detail element if you really wanted to, but then what's the point of using XML)
So basically in the end I think you do need to use some sort of error code instead manually parsing a string, but by creating your own SoapException you can use the detail element to put it in the right place. Learn about the soap fault and the SoapException, don't just let .NET hide it all from you.
Does anyone else have any ideas/opinions on this? Am I missing something?