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.