Re: Existing exception class for 403 or ! 0 errors from SoapClient
class?
david.karr wrote:
If you have a generic or somewhat application-specific "SOAP client"
class, that is intended to interface to multiple SOAP services, the
possibility exists that the HTTP communication with the server fails
with either a 403 or just something besides 200. The lazy approach is
to overload the "Exception" class with a specific message about the
HTTP-related error.
Is there an existing exception class that makes sense here? If not,
would it be "cheating less" to overload "SOAPException" with that HTTP-
specific error message?
I think I understand your description, and if so then your basic idea is
sound. Also, there are several standard API exceptions that you might use,
depending on what you're trying to accomplish and to communicate, and to whom.
Your terminology isn't standard, so let me rephrase to see if I got your
point. If you don't like one of the prefab exceptions, you want to derive a
class, that is, inherit from 'javax.xml.soap.SOAPException'. At least, that's
what I think you meant by "overload". [1] That's one thing that inheritance
is good for, to specify behavior based on but beyond that of an existing
implementation or specification (concrete class or interface).
You don't need to do anything special to put a message into most exceptions,
certainly not for 'javax.xml.soap.SOAPException'. It has two constructors
that take a String argument so you already can put any message you want in there.
<http://java.sun.com/javaee/6/docs/api/javax/xml/soap/SOAPException.html>
'javax.xml.soap.SOAPException' is a checked exception; it has to be declared
in the signature of a method that throws it. You have three things you
can/should do with exceptions: construct & throw, catch & throw, catch &
handle. The layer of your client that directly receives the SOAP message
probably shouldn't throw any 'SOAPException's, or exceptions derived
therefrom. You'd have to declare the exception (as 'SOAPException', not as
the subtype) in the method signature, and the exception would be revealed in
low-level gory detail to a higher level caller. If the low level must rethrow
an exception, it should be a higher-level exception that takes the
'SOAPException' as its 'cause' argument. It should log the exception before
rethrowing, if rethrow is what it does.
You have a lot of choices. You don't need to rethrow the exception after
logging. You could return a status that the navigation controller uses to
branch to an error-handling part of the application proper. Something like a
screen that politely informs the human, "I say, terribly sorry, old bean, but
something seems to have fubared with the service. Would you prefer that I
essay another linkup with it, or shall we turn our attention to something else
for the nonce?"
The gory technical details are for log files only.
[1] Many terms in Java have specific meanings, particularly those used in the
Java Language Specification. One of those is "overload".
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.9>
It is a very important word in Java, which is why it gets a whole chapter
section. It's distinct from "override" and not part of inheritance.
--
Lew