The Oracle ADF controller provides a declarative option for developers to define a view activity, method activity or router activity to handle exceptions in bounded or unbounded task flows. Exception handling however is for exceptions only and not handling all types of Throwable. Furthermore, exceptions that occur during the JSF RENDER RESPONSE phase are not looked at either as it is considered too late in the cycle.

For developers to try themselves to handle unhandled exceptions in ADF Controller, it is possible to extend the default exception handling, while still leveraging the declarative configuration. To add your own exception handler:

· Create a Java class that extends ExceptionHandler

· Create a textfile with the name “oracle.adf.view.rich.context.Exceptionhandler” (without the quotes) and store it in .adf\META-INF\services (you need to create the “services” folder)

· In the file, add the absolute name of your custom exception handler class (package name and class name without the “.class” extension)

For any exception you don't handle in your custom exception handler, just re-throw it for the default handler to give it a try

…

import oracle.adf.view.rich.context.ExceptionHandler;
public class MyCustomExceptionHandler extends ExceptionHandler {
public MyCustomExceptionHandler() {
     super();
}
public void handleException(FacesContext facesContext, 
                            Throwable throwable, PhaseId phaseId) 
                            throws Throwable
{
   String error_message;
   error_message = throwable.getMessage();
   //check error message and handle it if you can
   if( … ){  
       //handle exception
       …
   }
   else{
      //delegate to the default ADFc exception handler
       throw throwable;}
   }
}

Note however, that it is recommended to first try and handle exceptions with the ADF Controller default exception handling mechanism. In the past, I've seen attempts on OTN to handle regular application use cases with custom exception handlers for where there was no need to override the exception handler. So don't go for this solution to quickly and always think of alternative solutions. Sometimes a try-catch-final block does it better than sophisticated web exception handling.