2 Replies Latest reply on Oct 31, 2011 12:39 PM by Conrad Conrad

    I18n FacesMessages Java Exceptions

    Conrad Conrad Newbie
      Hi,

      how I am able to define translations for JAVA exceptions in the messages_en.properties file?
      For example: java.lang.NullPointerException, java.lang.NumberFormatException

      Thank you in advance.

      Regards,
      Conrad
        • 1. Re: I18n FacesMessages Java Exceptions
          Tim Evers Master

          I don't think this functionality exists straight out of the box.


          Even though I don't agree with your idea from a programming perspective. (If you are getting NPEs or NumberFormatExceptions or any other exception (well, almost any other exception see below) for that matter I would recommend you go back and re-think your strategy. You should be using try catch blocks for code where exceptions are a possibility. NumberFormatExceptions should be handled by your converter or validator and caught properly. And if there is a common operation that generates exceptions it should be wrapped up in a Utility class that contains the try catch block and adds the FacesMessage if necessary.) Ok, I'm done ranting.


          There are exceptions to this rule (pardon the pun). You may have your own type of exception that you want to deal with at a global level. Or like in my application we want to handle database timeouts or deadlocks in a relatively nice way. As you can see we also have not finished every feature of our app so we also handle NotImplementedYetExceptions.


          I do this with a Seam Interceptor. In the code below there is a lot of stuff that really is only relevant to my codebase. But, the idea is there and you should be able to figure it out by reading this in conjunction with the relevant Seam doco on Interceptors.


          @Interceptor(within={GekkoSpringInjector.class})
          public class GekkoExceptionInterceptor extends AbstractInterceptor {
              
              @Override
              public boolean isInterceptorEnabled()
              {
                 return true;
              }
          
              @Override
              @AroundInvoke
              public Object aroundInvoke(InvocationContext ctx) throws Exception { //NOPMD - Throw exception acceptable here 
                  
                  Object result = null;
                  try {
                     result = ctx.proceed();
                  }
                  catch( RuntimeException e ){
                      Throwable t = ExceptionUtils.getRootCause(e);
                      if( t instanceof ValidationException ){
                          FacesMessagesUtils.addErrorMessages((ValidationException) t);
                      }
                      else if( t instanceof NotImplementYetException ){
                          FacesMessagesUtils.addInfoMessage(t.getMessage());
                      } else if(t instanceof SqlEx) {
                          handleSqlException(e, t);
                      }
                      else {
                          throw e;
                      }
                  }
          
                  return result;
              }
          
              private void handleSqlException(RuntimeException e, Throwable t) {
                  SqlEx sqlEx = (SqlEx)t;
                  if (sqlEx.getMessage().matches("^Timeout occurred .*")) {
                      FacesMessagesUtils.addErrorMessage("Database timeout occurred. Please try again.");
                  } else if (sqlEx.getMessage().matches("^Deadlock detected, your single or multi-query transaction has been aborted.*")) {
                      FacesMessagesUtils.addErrorMessage("Database deadlock occurred. Please try again.");
                  } else {
                      throw e;
                  }
              }
          }
          



          Once you have handled the exceptions I'm sure you can work out how to map the name of the exception to a message.

          • 2. Re: I18n FacesMessages Java Exceptions
            Conrad Conrad Newbie

            First of all, thank you for the answer and for the posted solution. The problem is, that you are not able to catch internal framework exceptions. In my case someone has modified the HTTP request of a JavaServer Faces form. In such requests are often framework specific params. The validation of these params is managed by the framework components. So you are not able to catch the exception before the next view is rendering.


            I found a solution by implementing a PhaseListener.