2 Replies Latest reply on Feb 15, 2006 8:54 AM by thomas.diesler

    UndeclaredThrowableException

      I have a Java Service Endpoint that throws a custom Exception called FinderException (not javax.ejb.FinderException). The method on the Interface that the SE implements is as follows:

      Itinerary findItinerary(Long itineraryId) throws FinderException;


      The code for that custom exception class is as follows:

      public class FinderException extends java.rmi.RemoteException {
      
       public FinderException(String s, Throwable cause) {
       super(s, cause);
       }
      
       public FinderException(String s) {
       super(s);
       }
      }


      In the SE implementation class, I throw that custom exception in cases when I can not find a matching result in the DB for the supplied itineraryId. On the client side, I'm using Dynamic Proxies to execute the web service call. Now, when I make the call to findItinerary for an itineraryId that does not exist, I'm expecting that on the client side, I will be able to catch that FinderException and handle it appropriately. Unfortunately, what I get instead is an UndeclaredThrowableException which renders my try:catch useless. The stack trace I get is as follows:

      java.lang.reflect.UndeclaredThrowableException
       at $Proxy1.findItinerary(Unknown Source)
       at com.ati.client.ItineraryInfoTest.main(ItineraryInfoTest.java:13)
      Caused by: org.jboss.axis.AxisFault: Unable to find Itinerary with id=1
       at org.jboss.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:303)
       at org.jboss.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:142)
       at org.jboss.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1249)
       at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
       at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
       at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
       at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
       at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
       at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
       at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
       at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
       at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
       at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
       at org.jboss.axis.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:257)
       at org.jboss.axis.MessagePart.getAsSOAPEnvelope(MessagePart.java:684)
       at org.jboss.axis.Message.getSOAPEnvelope(Message.java:428)
       at org.jboss.axis.client.Call.invokeEngine(Call.java:3102)
       at org.jboss.axis.client.Call.invoke(Call.java:3064)
       at org.jboss.axis.client.Call.invoke(Call.java:2652)
       at org.jboss.axis.client.Call.invoke(Call.java:2561)
       at org.jboss.axis.client.Call.invokeInternal(Call.java:1982)
       at org.jboss.axis.client.Call.invoke(Call.java:1920)
       at org.jboss.webservice.client.CallImpl.invoke(CallImpl.java:265)
       at org.jboss.axis.client.AxisClientProxy.invokeSEIMethod(AxisClientProxy.java:286)
       at org.jboss.webservice.client.PortProxy.invoke(PortProxy.java:177)
       ... 2 more


      Can anyone help me to figure out if this is expected behavior and if not, what can I do to fix it?

        • 1. Re: UndeclaredThrowableException

          I have noticed that if my custom Exception classes do not extend RemoteException, then I get the correct handling on the client side. The SOAP Fault gets generated with the proper detail as follows:

           <soapenv:Fault>
           <faultcode>soapenv:Client</faultcode>
           <faultstring>Unable to find Itinerary with id=1</faultstring>
           <detail>
           <ns1:FinderException xmlns:ns1="http://com.ati.itinerary.model/ws/types">
           <message>Unable to find Itinerary with id=1</message>
           </ns1:FinderException>
           </detail>
           </soapenv:Fault>
          


          But if my exceptions do extend RemoteException, then the proper mappings do not get generated (by wscompile) in the WSDL (or jax-rpc mappings file either) and the client side handling does not work as expected. I wanted to try and simplify my Web Service Interface classes by not having to have them explicitly throw RemoteException. I was going to do this by having my base exception class extend from RemoteException so that all derived classes that are thrown by my interfaces will be RemoteExceptios thus not necessitating an explicit "throws RemoteException". Is this not going to be possible?

          Also, throwing a RemoteException derived class inside one of my Session Beans will cause a transaction rollback, which is what I want. If I can't have my exceptions extend RemoteException because of this webservice problem, is there another Exception that I can extend from to get transaction rollback? Does EJBException work the same way?

          • 2. Re: UndeclaredThrowableException
            thomas.diesler

            http://wiki.jboss.org/wiki/Wiki.jsp?page=WSExceptions

            From

            http://www-128.ibm.com/developerworks/xml/library/ws-tip-jaxrpc.html


            RemoteException

            JAX-RPC requires that all remote methods in a service endpoint interface (SEI) throw the standard java.rmi.RemoteException. This allows exceptions which arise from communications or runtime difficulties to propagate back to the caller. However, there is no portable means to send specific subclasses of RemoteException.

            The application itself could also throw a RemoteException. However, since there is no portable means of sending specific RemoteExceptions, the client cannot catch specific RemoteExceptions. For a given SOAP fault returned from the server, different client-side JAX-RPC runtimes may have different interpretations and generate different RemoteExceptions. Because of this interoperability problem, the application should avoid throwing RemoteExceptions.