Enforcing Component Constraints

Brent Putman putmanb at georgetown.edu
Thu Jan 26 18:56:10 EST 2017



On 1/26/17 2:49 PM, Cantor, Scott wrote:
> I think I've said in the past that I don't exactly get the point of documenting a parameter and then adding a check. If I'm checking, I'm apparently handling nulls. 

I think we'd disagree about the meaning of "handling" nulls in that
case.  To me, throwing an unchecked runtime exception
(ConstraintViolationException) isn't really handling it.  We're just
trading an NPE for a CVE with a slightly more useful message with
contextual info.  It's still fatal. 

Re Marvin's suggestion: OOH, It would be useful to automate the check
with an injected constraint check via AOP, etc, b/c it would avoid us
having to litter the code with all the manual constraint checking. 
OTOH, I imagine that the auto constraint checking might be dependent on
the environment, i.e. might be IdP-only (unless the Java8 stuff is
auto-applied to everything in a jar, etc, I haven't looked yet).  So
things like standalone library use would suffer if we removed the manual
constraint checks, unless the usage environment adopted the same
annotation enforcement technique(s).  I'm thinking about say
java-support and java-opensaml usage in other downstream projects, like
the metadata aggregator or a Java SP.

> I know that's what we're doing, but the pattern predates me.

It was a Chad-ism I guess (and IIRC maybe also an Ian-ism?), but I don't
really disagree with it.  In the absence of any automagical constraint
enforcement, it's better to me to get a fatal error with some contextual
info, rather than just a naked fatal NPE.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170126/5b3e6feb/attachment.html>


More information about the dev mailing list