Tapestry
  1. Tapestry
  2. TAPESTRY-1111

Throw an exception when trying to access an uninitialized property

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.7
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      If you do not specify a default value for a property (e.g. with @InitialValue), it gets initialized to a default value selected by Tapestry. This creates lots of opportunities for confusion and bugs. I suggest that instead, the property should be marked internally as "uninitialized". If you attempt to get its value while it is in that state, it should throw an exception. Looking up a property before its value has been set is almost always an error. It is much better to immediately alert the user so they can fix the bug, rather than letting their program appear to work, but misbehave in some possibly subtle way.

      This applies to any situation where you try to access a value that is not currently available. For example, if you try to access a persistent property inside pageAttached(), it should throw an exception rather than simply returning null.

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Sorry about that Peter. Another developer corrected me and pointed out the part about accessing properties that haven't been set while doing things in a pageAttached or similar sort of state.

        I can't make any promises about it getting done but will certainly look into it to see if it's possible to do without incurring any performance costs for the majority use case.

        Show
        Jesse Kuhnert added a comment - Sorry about that Peter. Another developer corrected me and pointed out the part about accessing properties that haven't been set while doing things in a pageAttached or similar sort of state. I can't make any promises about it getting done but will certainly look into it to see if it's possible to do without incurring any performance costs for the majority use case.
        Hide
        Jesse Kuhnert added a comment -

        Normally I'd be all for providing better/more intuitive defaults but don't think I agree in this instance.

        Tapestry doesn't do anything special to these properties, they are initialized by the jvm like any other member. If you have an int with no value specified it'll be -1. For any non native types it's usually null I think.

        In many instances this may actually be the desired behavior for people to have.

        As always, if you have a compelling argument for doing it your way the door is always open/tickets can be re-opened...I'm just not seeing it with the arguments given so far.

        Show
        Jesse Kuhnert added a comment - Normally I'd be all for providing better/more intuitive defaults but don't think I agree in this instance. Tapestry doesn't do anything special to these properties, they are initialized by the jvm like any other member. If you have an int with no value specified it'll be -1. For any non native types it's usually null I think. In many instances this may actually be the desired behavior for people to have. As always, if you have a compelling argument for doing it your way the door is always open/tickets can be re-opened...I'm just not seeing it with the arguments given so far.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Peter Eastman
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development