Enforcing Component Constraints

[Brent Putman]

On 1/26/17 7:47 PM, Cantor, Scott wrote:
> My point is it still incurs the small cost of a null check. To me the point of it all is to skip the cost by assuming the caller is to blame for doing it wrong.

Yes, it's true that the cost is > 0.  The cost of a stack frame push
and pop and null reference check is very very small in the grand scheme
of things.  But it is a cost.  However...


>
> It's case by case whether the result of a check is an unchecked or checked error or a return code, but it's all the same to me, it's assuming the caller isn't going to do it right.
>
> So, I would actually drop the checks and live with an NPE because I don't really need the context, the stack trace is going to tell me the line, same information I get from the exception message.

Note that: The callee method really could only drop the check if the
potentially-null arg was only going to be used internally within
itself, and in such as way that you know that a null would "safely"
result in an NPE. By "safely", I mean as opposed to proceeding with a
null value and "successfully" doing A Bad Thing(tm).  In particular, IF
it's going to be passed as an arg to another method which is
potentially @Nonnull (or otherwise doesn't accept nulls), then as the
(now) caller it has responsibility to not pass a null. So it has the
obligation to do the check, and incur the cost.

I don't know what subset of our methods with a @Nonnull arg fall into
which of the 2 categories (potentially safe to omit the check, vs not),
but I bet the case of an effectively obligatory null check is not
rare.  It may even be the majority. One could argue it's not worth
trying to fine tune the distinction, and special case the check
everywhere, and that for consistency's sake it's better to just
universally check the constraint, and incur the cost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170127/8d43dda7/attachment.html>