WebService Exceptions - Moderately Technical Post.
August 15, 2005 @ 08:03 AMOkay, Java developers. Check me on this.
The Problem Web Services do not really handle the concept of checked exceptions. At least, WebLogic 7’s implementation of them don’t. A web service throws a SOAP Fault which gets translated into a SOAPFaultException which is THEN wrapped inside of a java.rmi.RemoteException. (Using an RMI exception I guess makes sense if you accept RMI as a concept package instead of a specific technology, since Web Services are Remote Method Invocations, but have nothing to do with Java RMI, specifically.)
So, follow me here… On our server if you have an exception condition, you can create a java.rmi.RemoteException and throw it (and ONLY a RemoteException, though RuntimeExceptions may automatically get caught/wrapped/thrown?) On your client, you will be thrown a RemoteException. RemoteException.getCause() will be a SOAPFaultException, which will contain a getFaultString() that contains a bunch of information you likely don’t care about, as well as the original server-side exception’s message.
Server --> Throws RemoteException wrapping CustomException
Client --> Catches RemoteException wrapping SOAPFaultException.So, on the client side you are not able to catch checked exceptions based on conditions thrown from the server.
Applicable Pattern/Framework? I could not find a Java-based framework for handling exceptions thrown across the wire. If anyone is aware of one, please let me know.
The “Compromise.” I just finished this last night and I’m making a refactoring pass right now, so things could change slightly. However…
Ideally I wanted to create a framework that would let you catch checked exceptions. However, in the end I determined that was probably not the best option. I can’t think of any way that you can specify types of exceptions that a web service could throw - that’s the whole problem to begin with - and you’d need to be able to do that in order have checked exceptions. (Using the solution I provided below, you COULD create a Proxy that throws checked exceptions, therefore seemingly you would have that capability, however you’d still have to know at the Proxy what you expect a web service to throw. No compile-time safety.)
I did however manage to come up with what I believe(hope) is a great design utilizing RuntimeExceptions. I realize Runtime vs. Checked exceptions is a touchy debate, and do not intend to tackle that issue at this point. I do come down on the side of checked exceptions, with some caveats I will explain at a later date. If you are a Runtime exception guy/gal, you will enjoy my solution immensely.
The Solution So I basically built a serializable abstract exception. This exception knows how to marshal itself and subclasses to/from RemoteExceptions (unmarshalling could be done here, but I’ve moved it to a handler). Any exception you want to throw, create it via subclassing StarRemoteException. Then you end up with code similar to this (this is pseudo-code):
Server
@WebService
public Order getOrderById(int id) throws RemoteException {
RemoteException exception = new OrderNotFoundException().marshal();
throw exception;
}
Proxy
public Order getOrderById(int id) {
try {
webservicePort.getOrderById(id); // make your webservice call
} catch (RemoteException ex) {
/* unmarshal and throw StarRemoteException */
throw StarRemoteExceptionHandler.getInstance().unmarshal(ex);
}
}
Client(s)
...
try {
Order order = serviceProxy.getOrderById(-1);
} catch (OrderNotFoundException ex) {
// notify user.
}
...
Anyway, that’s my web services exception handling “framework.” Has anyone done anything similar? Or anything completely different that addresses the same issues?
Update: Added some rudimentary UML…
phaeosporeae angelophany ugsomeness safemaking atheological palaeoplain whaleroad prelect Iraqi troops cross line, skirmish with Kurds http://www.geographia.com/Chile/explora/exphotatac.htm