Tiles
  1. Tiles
  2. TILES-516

JSP exceptions are hidden by Tiles making debugging difficult

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When using tiles:insertDefinition, any exceptions thrown by the jsp renderer are being hidden from the logs by TilesContainer.

      Based upon apache's logging best practices(http://commons.apache.org/logging/guide.html), I believe it would be best if exceptions caught in TilesContainer's render methods were logged before being rethrown.

      "External Boundaries - Expected Exceptions. This classification includes exceptions such as FileNotFoundException that cross API/SPI boundaries, and are exposed to the user of a component/toolkit. These are listed in the 'throws' clause of a method signature.
      Appropriate handling of these exceptions depends upon the type of code you are developing. API's for utility functions and tools should log these at the debug level, if they are caught at all by internal code.
      For higher level frameworks and middleware components, these exceptions should be caught immediatly prior to crossing the API/SPI interface back to user code-space, logged with full stack trace at info level, and rethrown. The assures that the log contains a record of the root cause for future analysis in the event that the exception is not caught and resolved as expected by the user's code. "

        Activity

        Hide
        Antonio Petrelli added a comment -

        Version?

        Show
        Antonio Petrelli added a comment - Version?
        Hide
        Clayton Rabenda added a comment -

        2.2.0

        Show
        Clayton Rabenda added a comment - 2.2.0
        Hide
        Antonio Petrelli added a comment -

        Did you try 2.2.2?

        Show
        Antonio Petrelli added a comment - Did you try 2.2.2?
        Hide
        Antonio Petrelli added a comment -

        The OP did not answer to our questions and his request is incomplete. Sorry I have to close it.

        Show
        Antonio Petrelli added a comment - The OP did not answer to our questions and his request is incomplete. Sorry I have to close it.
        Hide
        Clayton Rabenda added a comment -

        Sorry Antonio,
        I will try to get back to this in the near future. My bug report was based on using 2.2.0 but I also took a look at the code for 2.2.2 and was really basing this bug report off of that. I'm basically just trying to argue that there should be some logging before all the throws in the render methods in BasicTilesContainer.

        I'm currently at the end of a project and trying to meet a deadline and also am moving to Zurich from the US on Saturday so very much starved for free time at the moment. Once I am settled down I will give 2.2.2 a try and let you know what I find.

        If you want to reproduce this, you can just use any malformed xml in a jspx as a template and observe that the original exception will not be available in the log... It may also simply be that I have something misconfigured.

        Show
        Clayton Rabenda added a comment - Sorry Antonio, I will try to get back to this in the near future. My bug report was based on using 2.2.0 but I also took a look at the code for 2.2.2 and was really basing this bug report off of that. I'm basically just trying to argue that there should be some logging before all the throws in the render methods in BasicTilesContainer. I'm currently at the end of a project and trying to meet a deadline and also am moving to Zurich from the US on Saturday so very much starved for free time at the moment. Once I am settled down I will give 2.2.2 a try and let you know what I find. If you want to reproduce this, you can just use any malformed xml in a jspx as a template and observe that the original exception will not be available in the log... It may also simply be that I have something misconfigured.
        Hide
        Clayton Rabenda added a comment - - edited

        One other thing. There are ways to work around this, I have been able to simply catch the exceptions in the jsp myself using c:catch and display them directly in the html output so it's possilble that you could consider this a non-issue, but I would argue that hiding an exception is not preferable.

        Show
        Clayton Rabenda added a comment - - edited One other thing. There are ways to work around this, I have been able to simply catch the exceptions in the jsp myself using c:catch and display them directly in the html output so it's possilble that you could consider this a non-issue, but I would argue that hiding an exception is not preferable.
        Hide
        Antonio Petrelli added a comment -

        In fact the exception is not hidden, it is passed to the upper layers. It is a well known best practice: fail fast.
        I think that you can see the stacktrace in your log, it is not necessary (nor advisable) to see it in your page.
        About log-and-throw, it is not advisable: either log or throw an exception (with cause), not both. Otherwise, you will see a double stacktrace.

        However, if you are referring to an exception thrown without cause, then you are right. If it is the case, please indicate the line where this happens.

        Thanks

        Show
        Antonio Petrelli added a comment - In fact the exception is not hidden, it is passed to the upper layers. It is a well known best practice: fail fast. I think that you can see the stacktrace in your log, it is not necessary (nor advisable) to see it in your page. About log-and-throw, it is not advisable: either log or throw an exception (with cause), not both. Otherwise, you will see a double stacktrace. However, if you are referring to an exception thrown without cause, then you are right. If it is the case, please indicate the line where this happens. Thanks
        Hide
        Clayton Rabenda added a comment -

        Okay, in that case, thanks for enlightening me, just leave this closed. The exception does have a cause, AFAIK, but it doesn't show up in the log...

        The docs for RuntimeException read "Note that the detail message associated with cause is not automatically incorporated in this runtime exception's detail message. "
        http://download.oracle.com/javase/6/docs/api/java/lang/RuntimeException.html

        Perhaps that is the root of my problem...?

        Anyway, thanks for your time. If you have any advice regarding this it would be greatly appreciated. As you pointed out, spitting out exception messages into the page is less than ideal.

        Show
        Clayton Rabenda added a comment - Okay, in that case, thanks for enlightening me, just leave this closed. The exception does have a cause, AFAIK, but it doesn't show up in the log... The docs for RuntimeException read "Note that the detail message associated with cause is not automatically incorporated in this runtime exception's detail message. " http://download.oracle.com/javase/6/docs/api/java/lang/RuntimeException.html Perhaps that is the root of my problem...? Anyway, thanks for your time. If you have any advice regarding this it would be greatly appreciated. As you pointed out, spitting out exception messages into the page is less than ideal.
        Hide
        Antonio Petrelli added a comment -

        Clayton, the fact that you are not seeing the stacktrace is terribly strange. It seems that some code (the servlet container?) is swallowing the exception.
        To help track your problem, try to write a servlet filter that makes a try/catch and logs any exception, rethrowing it if it is a RuntimeException.

        What container are you using?

        Probably (just a shot in the dark) you are watching the wrong log: you should see the server log, not the application log.

        Show
        Antonio Petrelli added a comment - Clayton, the fact that you are not seeing the stacktrace is terribly strange. It seems that some code (the servlet container?) is swallowing the exception. To help track your problem, try to write a servlet filter that makes a try/catch and logs any exception, rethrowing it if it is a RuntimeException. What container are you using? Probably (just a shot in the dark) you are watching the wrong log: you should see the server log, not the application log.

          People

          • Assignee:
            Unassigned
            Reporter:
            Clayton Rabenda
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development