Doug Ross @ Journal

Friday, June 18, 2004

Return-codes vs. Exceptions, part 417

I can't resist. I am compelled... yes, compelled... to continue the saga of return-codes versus exceptions. Especially since I remembered SOAP. You know, the typical RPC (or even LPC) method of invoking an object. SOAP seems to throw a very large, titanium monkey-wrench into the oh-so-pristine world of exceptions. Consider this RogueWave example of a SOAP call:



	RWSoapMessage myResponse;

	myResponse.extract(someHttpReply.getBody());

	RWSoapBody mySoapBody = myResponse.getSoapBody();



	if( mySoapBody.hasSoapFault() ) {

	   RWSoapFault mySoapFault = mySoapBody.getSoapFault();

	   // Do something here

	}

In other words, classic RW processing handles the SOAP fault inline, just as it would with a return-code. No exceptions flying around. And that makes sense, given the fact that we have a return-code (or, as SOAP calls it, a fault-code) in the returned XML document.

In fact, JavaWorld goes so far as to say (emphasis ours):

Let's focus on the Fault element defined in the http://schemas.xmlsoap.org/soap/envelope/namespace. All SOAP servers must always return any error condition in that element, which is always a direct child of the Body element. Without exception, the Fault element must have faultcode and faultstring elements. The faultcode is a code that can identify problems; client-side software uses faultcode for algorithmic processing as the SOAP specification calls it. The SOAP specification defines a small set of fault codes that you can use. The faultstring on the other hand is meant for human consumption.

In other words, when you make calls to objects, you expect to get return-codes back. If you choose to throw exceptions at that point, you can. But it really doesn't serve much of a purpose, since you've got a code (and error text) which tells you everything you need to know to recover gracefully from the fault.

1 comment:

Anonymous said...: Lets see, we can’t use exceptions in SOAP therefore we shouldn’t use them in our regular Java programming. C doesn’t support exceptions therefore would shouldn’t use exceptions in C++/Java/C#/VB/Any other exception throwing language.

SOAP, whatever the creators intended it to be, isn’t good enough to write normal code. It is only good at writing the interface. When I was writing web service code almost all of the code that I wrote was regular Java, exception-throwing code. Only at the very last layer before SOAP did I catch all exceptions and return an appropriate error code. This was almost certainly the right way to do it. Now any other Java programmer can call my code directly and get all the language (including exceptions) benefits of Java.

So SOAP doesn’t support exceptions, so what, neither does serializing data and pumping it down a socket. SOAP is a glorified (and fairly easy to use) TRANSPORT mechanism. To view it as anything else would be mistaken.

-Tom; 7:34 AM