Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Navigation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      511
    • Status Whiteboard:
      Hide

      cat2 frame size_medium importance_medium

      Show
      cat2 frame size_medium importance_medium

      Description

      Exceptionhandling is a common aspect throughout an application. As JSF right
      now does not support exceptionhandling at all, this needs to be done within the
      applications action methods. This often leads to action methods which contain
      more lines of code handling exceptions than doing the actual work. Which in the
      end leads to less readable code as the primary concern of the action dissolves
      within a secondary aspect in this case exception handling.

      Now here is my suggestion to incorporate exceptionhandling by simply extending
      the navigationrules.

      First, exceptions should be considered legal outcomes. Therefore an additional
      tag called "from-exception" should be introduced to the navigation case which
      can be used instead of the "from-outcome" tag to define an exception case. It
      could just be filled with the exceptions class name. As it seems obvious that
      in some cases there is more to exceptionhandling than navigating to another
      view, it should also be possible to define an exceptionhandler which is called
      in an exception case before navigation is done. This could be done by
      an "exception-handler" tag which might contain a method binding to some method
      handling the exception where the exception itself should probably be passed as
      a method parameter.

      Here is a simple login example on how such a solution could look like:

      1. The navigation rules in faces-config:

      <navigation-rule>
      <from-view-id>/login.jsp</from-view-id>
      <navigation-case>
      <from-action>#

      {pcLogin.doLoginAction}</from-action>
      <from-exception>myapp.exception.LoginFailedException</from-exception>
      <to-view-id>/login.jsp</to-view-id>
      <exception-handler>#{pcLogin.loginFailed}</exception-handler>
      </navigation-case>
      <navigation-case>
      <from-action>#{pcLogin.doLoginAction}

      </from-action>
      <from-outcome>success</from-outcome>
      <to-view-id>/someOther.jsp</to-view-id>
      </navigation-case>
      </navigation-rule>

      2. The action method in bean "pcLogin":

      public String doLogin() throws LoginFailedException {
      someSecurityContext.login(user, pass); // This throws
      LoginFailedException
      return "success";
      }

      3. The exception handler method in bean "pcLogin":

      public void loginFailed(Exception exception) {
      logger.warn(exception);
      FacesContext.getCurrentInstance().addMessage(new FacesMessage("Login
      failed!"));
      }

      In this example the benefit is rather small although at least the concerns are
      separated into two methods, but within larger application you could work with
      generic exception handlers which are able to handle exception in a common way
      for many different actions. I faked this behaviour in some of my applications
      by using an action listener and a separate configuration file for defining
      exception cases and it really leads to much better readable action methods.
      Another nice feature of this solution is that you could define fallback rules
      which catch all unexpected exceptions.

      <navigation-rule>
      <navigation-case>
      <from-exception>java.lang.Exception</from-exception>
      <to-view-id>/error.jsp</to-view-id>
      <exception-handler>#

      {pcFallback.handleUnexpectedException}

      </exception-
      handler>
      </navigation-case>
      </navigation-rule>

      Best regards

      Frank

        Activity

        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Hanspeter Duennenberger added a comment -

        Would <from-exception> evaluate on the current caught exception only or also evaluate all it's causes? And if causes are to evaluated - starting on deepest cause or on the outer exception?

        Since this will only cover exceptions from actions it might be better to define a standard ExceptionHandler that can apply many such rules. That would also work for any other method call like e.g. value expression.

        Show
        Hanspeter Duennenberger added a comment - Would <from-exception> evaluate on the current caught exception only or also evaluate all it's causes? And if causes are to evaluated - starting on deepest cause or on the outer exception? Since this will only cover exceptions from actions it might be better to define a standard ExceptionHandler that can apply many such rules. That would also work for any other method call like e.g. value expression.
        Hide
        kaiserinspe added a comment -

        Evaluating the exceptions causes is an interesting idea I didn't had in mind when I postet this request two years ago. It would at least ease up handling of wrapped exceptions thrown by some application backend. This probably should be a feature which can be turned on and off on demand. I believe standard behaviour of such an exception based rule should be the same as within a Java catch clause, because that is what most people would expect it to be. The "from-exception" tag mentioned in the original request could have an attribute "matches" which could have values like "exact" which matches only the exact exception or "causesFromRoot" / "causesFromTop" which matches the causes aswell. Maybe there are other useful matching types if we give it further thought. Maybe there's even room for a pluggable mechanism.

        You are absolutely right about the fact that an exception based navigation rule will only apply to exceptions thrown in actions. This is a drawback. Therefore it makes sense to have a general exception handling mechanism. Nevertheless the ability to be able to navigate on behalf of exceptions thrown by actions is a very reasonable feature. This is because especially with actions exceptions are actually part of the applications flow and therefore should be incorporated into its navigation rules. In other parts of the application like event handlers, phase listeners, etc. where navigation is not affected directly but exception handling needs to be done aswell a general exception handler mechanism would be a very good idea.

        Show
        kaiserinspe added a comment - Evaluating the exceptions causes is an interesting idea I didn't had in mind when I postet this request two years ago. It would at least ease up handling of wrapped exceptions thrown by some application backend. This probably should be a feature which can be turned on and off on demand. I believe standard behaviour of such an exception based rule should be the same as within a Java catch clause, because that is what most people would expect it to be. The "from-exception" tag mentioned in the original request could have an attribute "matches" which could have values like "exact" which matches only the exact exception or "causesFromRoot" / "causesFromTop" which matches the causes aswell. Maybe there are other useful matching types if we give it further thought. Maybe there's even room for a pluggable mechanism. You are absolutely right about the fact that an exception based navigation rule will only apply to exceptions thrown in actions. This is a drawback. Therefore it makes sense to have a general exception handling mechanism. Nevertheless the ability to be able to navigate on behalf of exceptions thrown by actions is a very reasonable feature. This is because especially with actions exceptions are actually part of the applications flow and therefore should be incorporated into its navigation rules. In other parts of the application like event handlers, phase listeners, etc. where navigation is not affected directly but exception handling needs to be done aswell a general exception handler mechanism would be a very good idea.
        Hide
        Ed Burns added a comment -

        Now that we have a pluggable exception handler, this is not an issue.

        Show
        Ed Burns added a comment - Now that we have a pluggable exception handler, this is not an issue.
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Unassigned
            Reporter:
            kaiserinspe
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: