function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

CalloutException: Problem with contents of fault detail?

We're having a problem with handling a fault coming back from a Callout.  We are getting an exception stating we received a SOAP fault (we want the fault for the purposes of testing error handling), and I'm unclear on the real problem-- is the problem with our ability to get to the fault data, or did we create a problem with the content of our fault, hence triggering the exception.


I have a couple of questions:


1) Normally, does any fault throw an exception, or would a fault appear in the response?  I haven't found anything in the documentation that explicitly explains how faults are handled.


2) What other methods and members are available for me to examine in the CalloutException other than the common methods (getCause()/getMessage())?  Again, the documentation is vague, and I can't find anything absolute that says CalloutException exactly what CalloutException provides (e.g. like JavaDocs for the APIs).


3) The exception we recieve manages to display the standard faultcode and faultstring, and the faultstring appears as what is provided by the exceptions's getMessage() method.  This gives me the sense that the fault is completely successfully parsed, or I'm getting a really poor error message from the API.  Below is the full SOAP Fault we receive.  I read another forum message indicating namespace prefixing was required for items in the detail of the message.  As far as I can tell, this is legal syntax, and other tools importing this WSDL handle faults properly: 



<S:Envelope xmlns:S="">
    <ns2:Fault xmlns:ns2="" xmlns:ns3="">
      <faultstring>"IGI0120:CBM5644:The Telephone Number Area Code is incorrect."</faultstring>
        <AAAError:AAAError xmlns="AAA" xmlns:AAAError="AAA">
            <MSGTEXT>"IGI0120:CBM5644:The Telephone Number Area Code is incorrect."</MSGTEXT>


I can partially answer your questions.


- SOAP faults are analogous to Apex/Java exceptions, so in general, a SOAP handler should translate all faults into exceptions. I'm 90% sure that Apex translates all faults into exceptions.

- The Apex exception page implies that the only Exception classes with additional methods are DMLException and EmailException.


For the rest of your question, I'm not clear exactly what you are asking. Are you simply not seeing all of the data from the fault get surfaced through the Exception API, such that you can't tell what fault you received? From the example you give, it seems that getting the faultstring should be sufficient to determine what the reason for the error was.


Jeremy Kraybill

Austin, TX




Thanks for the reply.

I am not seeing all of the data from the fault, and I'm not sure how to navigate using the CalloutException to review the contents of the fault object. 


As soon as the exception is thrown, we end up in a catch block, where there seems to be no documented access to the fault object.  The text of the fault is only being provided by the CalloutException.getMessage(), where the faultstring, faultcode, and faultactor have been concatenated to some arbitrary number of characters.  I have no way of accessing those pieces of data individually, nor can I review the detail message that I'm providing back.


I reviewed the Apex exception page you referenced earlier -- I was hoping there was something more absolute.


If you (or anyone else) has an example fault message that's legal, and/or example fault handling code, I'd love to see it -- the documentation I see from SFDC seems to skirt around any detail in this case.



Thanks again!


Based on what you are saying, I would say you are most likely out of luck. Within Apex, the exception object is the fault object -- Apex translates the SOAP fault into an exception. So if Apex isn't mapping all the data from the fault into the exception, it's probably lost.


You probably need to find out from Salesforce support if this is indeed the case. If you do, please post the info here.


If your SOAP responses are very simple, one workaround you may want to consider is making the SOAP request "by hand" using HttpRequest and a SOAP string. This is really undesirable if you need to parse complex return types, but you do get the full SOAP response, and could do whatever you need to get the full fault data.


Jeremy Kraybill

Austin, TX


Well, we do have a ticket open now.


Daniel BallingerDaniel Ballinger

I know this is a really old thread, but did you get anywhere with this?


I'm having a very similar issue in that the CalloutException Message only contains part of the underlying fault code and the remainder gets truncated. In my case it is the part that has been truncated that contains the useful information so I need to resort to using an external tool like soapUI to capture the outbound messages and replay them to the web server.


I need fault string to be returned from a custom error list.  Need help. 


I never got a meaningful resolution from SFDC and moved on.  I don't know if things have improved with the latest releases.

Daniel BallingerDaniel Ballinger

Thanks. I've got a similar question open (Accessing the entire fault response from a CalloutException) but I suspect this is just how Apex works with web service exceptions.


I did find SOAPFault Information for Apex on IdeaExchangewhich may be worth promoting.