• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JAX-WS exception handling

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reading Ivan Kriznan's notes, section 9.6, I got the impression that a service annotated with @WebServiceProvider should not throw exceptions. Instead, it should return a SOAPFault in the message body and the client is responsible for checking by calling hasFault on the SOAPBody.
Is that a correct understanding? I'm also curious in knowing the best practices for throwing exceptions on the server side, as I didn't find any good documentation about that. Should you throw checked exceptions and make the client handle it? The industry seems to be moving away from checked exceptions, which IMHO as well, unnecessarily clutters the client code. How does exception handling differ between @WebServiceProvider and @WebService classes?
 
a sarkar
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After some research, I think I can answer my own question.

If the service publishes a WSDL, it can throw service exceptions (ones mapped in the WSDL) or unmapped exceptions (RuntimeException or it's subclass). Service exceptions are wrapped in a SOAPFaultException and the service exception becomes the detail. If the service does not publish a WSDL, it should only throw RuntimeException or it's subclass because it's clients will have no knowledge of any checked exceptions even if it throws one. It may also not throw any exception and just set the body of the response to a SOAPFault, but in IMHO, it's a good programming practice to throw exceptions explicitly rather than leaving it up to the client to check for faults.

On the client side, if the client is a dynamic proxy type, it will see service exceptions in the form of the generated exception class and unmapped exceptions as a ProtocolException subclass, which almost always is SOAPFaultException class.
If the client is a dispatch type, regardless of how the service is implemented, it'll see the exception in the form of a ProtocolException subclass, which almost always is SOAPFaultException class.
 
Bartender
Posts: 2418
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Ivan's StringProcessor example on p.161 of his notes, Ivan provides us a wsdl first. Then, from the WSDL, we generate the JAXB elements.
Next, Ivan create a service with @WebServiceProvider (wsdlLocation="stringProcessorService.wsdl")
In this case, the client (with SEI generated from the wsdl) uses the URL of endpoint address to invoke the service.
So, I think the client can still know what exception will be thrown.
 
a sarkar
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Himai Minh wrote:I think the client can still know what exception will be thrown.


If it's a dynamic proxy client, it'll have a client side exception class generated by wsimport. The client will not know what actual exception the service threw - the JAX-WS runtime will map the SOAP fault to the client side exception. The point to be noted is, the client may not even be written in Java so transmitting server side Java exceptions is useless. Not the least of concerns is tight coupling; if a Web Service gives out server side information to the client, we might as well use an EJB as was done in the 2000.
 
Himai Minh
Bartender
Posts: 2418
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To comment my own post, the Provider<T> implemented by the service only provides invoke(T source) method. But this method does not throw any checked exception. So, the client can only get RuntimeException.
 
a sarkar
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Is there any way to change the faultcode to "Client" while using WSDL mapped service specific faults and @WebFault annotation?
 
Himai Minh
Bartender
Posts: 2418
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the exception is thrown from the server, then the faultcode is ns2:Server.
If the fault is caused by the client, then the faultcode is ns2:client.

Can we as a programmer decide who (server/client) causes the exception?
 
a sarkar
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Himai Minh wrote:If the exception is thrown from the server, then the faultcode is ns2:Server.
If the fault is caused by the client, then the faultcode is ns2:client.

Can we as a programmer decide who (server/client) causes the exception?


If the exception is due to a client error (say validation error), the fault code should reflect that. I, however, didn't find any way to change that using @WebFault annotation.
 
reply
    Bookmark Topic Watch Topic
  • New Topic