Open Stack

>
> I'd actually be fine with this just failing in all cases where null isn't
> a valid input to the function. We want it to fail as early as possible
> though, and the currently handling for get_attr is going to get in the way
> of that. (We currently try to delay checking for None as long as possible,
> because get_attr may not start returning a non-None value until runtime.)
> Maybe that means we should tackle this after the placeholder stuff is
> implemented, so that we can enforce earlier detection of errors?
>

I think we can let placeholder as a solution when null becomes an input to
the function. We will have a placeholder as the input (instead of null),
and check type with the placeholder to make sure we get to fail as soon as
we can. If the type is correct, we will check the real value when we
actually got one. With this part of spec in placeholder, I think we can
avoid blind check (and parse) with null value (which is the main reason of
bug [1]).
Worth mention that when dealing with null input value, parameter will parse
it to the `default value` of that type (0 for number, '' for string),
 which will allow as to pass the check, but miss a chance to find out the
error of why the input value is null (it just accept `default value` as the
input, but it might not be the what we design in the template). Also
`default value` not always the correct input (for some number properties, 0
is not allowed). I think with placeholder, we will never need to replace
null with `default value`.

+1 for gain enforce earlier detection of errors with placeholder. We can
make it as part of placeholder spec, or the one right next.
Any feedbacks to the spec [2] are welcome.

[1] https://bugs.launchpad.net/heat/+bug/1559807
[2] https://review.openstack.org/#/c/392499/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161212/270d11c0/attachment.html>