A (hopefully short) two cents: 1) Usually, I prefer to propagate exceptions rather than error codes. Exceptions really can make application flow simpler. I agree that 'cooking' the exception is good: the topmost layer that has an additional useful detail should add it; also, it's often nice to wrap an exception to provide a consitant interface (wrap an SQLException in a FooSubsystemException so different implementations can use a database, a file system, etc.) Error codes are good when the alternate behaviour isn't really 'exceptional' -- happens, say, 30+% of the time anyway. 2) That said, when passing exceptions -- particularly chained ones -- over a remote interface you want to create an exception class specifically for the interface and only give it basic types as fields -- no chained exceptions here. This is because you don't want to have all the server exceptions in the client jar. Axis handles this somewhat gracefully (you get a null): RMI throws it's own exception if a class isn't available upon deserialization. This lets the client recognise a server fault, get some information back about it and decide what to do.
Hope that was helpful :) Chris -----Original Message----- From: Jeff [mailto:[EMAIL PROTECTED] Sent: Thursday, June 02, 2005 8:41 AM To: axis-user@ws.apache.org Subject: Re: web service error handling design issue Life is never that simple, James! Academics are prone to produce bland generalizations and are notorious for being out of touch with reality, though I suspect that this is due to a few loonies giving the rest a bad name! Clearly, most academics do a great deal of invaluable work for which they have my deepest gratitude. I once heard that a university professor who claimed that it wasn't possible to write more than 10 lines of fully debugged code per day. I've been developing software for 25 years and if my output was anything like that I'd have gone broke years ago! Only a few months ago at a Java Users Group meeting I overheard an academic stating with conviction that "If you have to use a case statement then you didn't do your OOD properly." -- yeah, right...cretin. To answer your question: in any software system, at any point between where an error occurs and where the outer-most calling code needs to know about the error, it is potentially appropriate to cook the error. In many circumstances it is inappropriate for calling code to know the simple, raw reason why an error occurs. For example, suppose that during some web service method call a required file was discovered to be absent from its expected location on a disk. Should you tell the web service client about this? Most likely not, because that piece of information is unlikely to be meaningful to the client. Instead, code much closer to error needs to figure out the consequences and throw an interpretation up the chain where other code might be able to do something to fix the problem (e.g. create a new file from default values and retry) or to rethrow a more intelligible error. Unfortunately, cooking errors is something that often doesn't happen because too many programmers have higher priorities and finite deadlines. How many times have you seen a ClassCastException and wondered which class the code was attempting to cast to? One poorly handled error can result in a great deal of wasted time, collectively over thousands of people. Also, please note that there are many types of error and you need to be aware that during software development we see errors (that tend to be uncooked) that arise through flaws in the logic of the software and will go away once the code has been debugged but, as an aid to development, we might want to cook them if they are not immediately resolvable. As I said, reality is rarely simple, at least not when human beings are involved. BTW, this is not a design issue, it's about writing good software. Jeff Between the question and the answer, all too often, lies pure hell ----- Original Message ----- From: "James Taylor" <[EMAIL PROTECTED]> To: <axis-user@ws.apache.org> Sent: Thursday, June 02, 2005 10:22 AM Subject: web service error handling design issue Hey, another design issue on a different note. In our college course we a told to propogate error up to the top layer/controller and deal with them appropriately. What's the best way to deal with errors in the case of web services? Should I catch the exception and return an appropriate fault node/code and deal with this in the client code or catch the error at the service provider top level and return an appropriate explanation? Just looking for ideas and what way is it done in industry. Thanks to anyone that gives my the time to answer, James. -- Between the question and the answer lies free will
