In this recipe, we will amend the implementation of our web service example from the Annotating the service endpoint interface with @SOAPBinding recipe.

We will change the source code of our example so that it will throw an exception in case there is a problem with processing a credit card operation. Now, if we run the example, even if the authorization fails, the processing is performed further. A more correct approach would be to handle faults and stop processing if a fault occurs.

We open the CreditCardGateway.java file in JDeveloper and search for the AuthoriseCreditCard method. We change the code so that it throws the exception if the expiry date cannot be recognized. An excerpt of the modified code is next:

public TransactionResponse AuthoriseCreditCard(CreditCardData ccd, BigDecimal amount) throws Exception {

  try {
    . 
    Date today = new Date();
    Date date = new SimpleDateFormat("MM/yy", Locale.ENGLISH).parse(expiry);
    .  
  } catch (ParseException e) {
    throw new Exception("Unable to parse date.");
  }

  return new TransactionResponse("Success.", 10000, UUID.randomUUID().toString());  
}

Right-click on the web service node in JDeveloper and select Regenerate Web Service from Source. As a result, we get newly annotated Java code.

We identify no change regarding the annotations in the code and also WSDL remains the same. However, deploying and running the web service now captures the fault in case of problems with parsing the expiry date.

We used the Exception class in order to throw the exceptions. Usually, it is recommended to use a named exception as they bring more expressiveness to the integration plus the additional possibility for the BPEL process to use the <catch> activity which captures name exceptions/faults. We will create a named exception and use it for the same purpose; that is, parsing dates.

We create a new class in JDeveloper and name it ExpiryDateException. We override the default constructors of the Exception class.

Now, we change the AuthoriseCreditCard method signature of the CreditCardGateway class, as shown in the following code snippet:

public TransactionResponse AuthoriseCreditCard(CreditCardData ccd, BigDecimal amount) throws ExpiryDateException {
and change the catch part of the exception handling:
  } catch (ParseException e) {
    throw new ExpiryDateException("Unable to parse date.");      
    //e.printStackTrace();      
    //return new TransactionResponse("Expiry date invalid.", 1002, null);
}

Originally, the fault thrown from the web service was as follows:

<detail>
  <ns2:exception xmlns:ns2="http://jax-ws.dev.java.net/" class="java.lang.Exception">
    <message>Unable to parse date.</message>
    <ns2:stackTrace>
       <ns2:frame class="org.packt.cc.business.CreditCardGateway" file="CreditCardGateway.java" line="54" method="AuthoriseCreditCard" />
     </ns2:stackTrace>
  </ns2:exception>
</detail>

With the newly defined exception, the fault information gets slightly different and more informative:

<detail>
  <ns2:exception xmlns:ns2="http://jax-ws.dev.java.net/" class="org.packt.cc.exception.ExpiryDateException">
    <message>Unable to parse date.</message>
    <ns2:stackTrace>
      <ns2:frame class="org.packt.cc.business.CreditCardGateway" file="CreditCardGateway.java" line="53" method="AuthoriseCreditCard" />
    </ns2:stackTrace>
  </ns2:exception>
</detail>