Velocity
  1. Velocity
  2. VELOCITY-758

Include line number in message "#parse() null argument"

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.6.2
    • Fix Version/s: 1.7, 2.x
    • Component/s: Engine
    • Labels:
      None

      Description

      Assume the following scenarios:

      Scenario A)
      A template has the following line:
      #parse("never-found-template.vm")

      Scenario B)
      A template has the following line:
      #parse($nonsense)

      Assume further, that neither the "never-found-template.vm" is present nor the variable "$nonsense" is set.

      In scenario A) the log reports "#parse(): cannot find template 'never-found-template.vm', called from template ... at (1, 1)"
      In scenario B) the log says "#parse() null argument"

      Problem:
      In scenario B), having multiple nested #parse-Statements, it's hard to find the error finally.

      Sugestion / Feature request:
      Include source information and line numbers when reporting "#parse() null argument" - analogous to scenario A)

      Thanks and kind regards

      Edy Hinzen

      1. velocity-758.patch
        3 kB
        Jarkko Viinamäki

        Activity

        Hide
        Jarkko Viinamäki added a comment -

        This should fix it.

        Note that the Velocity code is full of cases where an Exception is not thrown and instead some (often very uninformative) message is written to the log. Someone should find the time to fix all those cases.

        Show
        Jarkko Viinamäki added a comment - This should fix it. Note that the Velocity code is full of cases where an Exception is not thrown and instead some (often very uninformative) message is written to the log. Someone should find the time to fix all those cases.
        Hide
        Nathan Bubna added a comment -

        I'm not sure that throwing an exception for #parse($nullref) is the thing to do here. For that matter, i don't think the current behavior is correct either, since it precludes the include event. Seems to me we should give any IncludeEventHandler the shot ot replacing a null value. And if the value is still null, then we should render "#parse($nullref)" instead of throwing an exception. When not in strict mode, i think exceptions should be limited to syntactical errors as much as possible. Null values are not syntax errors.

        Show
        Nathan Bubna added a comment - I'm not sure that throwing an exception for #parse($nullref) is the thing to do here. For that matter, i don't think the current behavior is correct either, since it precludes the include event. Seems to me we should give any IncludeEventHandler the shot ot replacing a null value. And if the value is still null, then we should render "#parse($nullref)" instead of throwing an exception. When not in strict mode, i think exceptions should be limited to syntactical errors as much as possible. Null values are not syntax errors.
        Hide
        Nathan Bubna added a comment -

        On second thought, i like the event handler support for null meaning don't render. So we just log the null reference and blockinput. I do still want to give the event handler a shot at null values.

        Show
        Nathan Bubna added a comment - On second thought, i like the event handler support for null meaning don't render. So we just log the null reference and blockinput. I do still want to give the event handler a shot at null values.
        Hide
        Edy Hinzen added a comment -

        Thanks, guys

        Show
        Edy Hinzen added a comment - Thanks, guys

          People

          • Assignee:
            Unassigned
            Reporter:
            Edy Hinzen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development