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

          People

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

            Dates

            • Created:
              Updated:
              Resolved: