Checking contextual integrity

[Daniel Fisher]

On Wed, May 29, 2013 at 5:16 AM, Rod Widdowson <rdw at steadingsoftware.com>wrote:

> More status.
>
> The upshot of the discussion on Friday was that we actually do need to
> tristate in these situations (yes/no/failure), either explicitly or via
> throwing an exception.
>
>
I agree with Scott that the yes/no/throw implementation is undesirable and
confusing.
My inclination with these sorts of interfaces is determine whether the
throw scenario is really *exceptional*.
I try to avoid throwing exceptions as part of the normal execution of any
routine.
You're better off if exceptions represent things that shouldn't
happen regularly.



> This means that our use of Predicate (from Guava) becomes problematic since
> they do not understand tristate and making them throw a (checked) Exception
> would change the signature so they wouldn't be Predicate any more.
>
> Tom and I discussed this yesterday.  There are 3 ways to do this all of
> which have down sides.  I have no particular favourite from any of them
>
> 1) Keep the current code but arrange for the Predicates to throw an
> unchecked Exception.  Then in the upper layers we can either convert this
> to
> a FilteringException or "do the right thing" - which is to say log the
> error, deny *all* attribute release (we have to do this since we cannot
> know
> the scope of the operation). This worries me somewhat (but then so do all
> the options)
> http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html .
>
>   Since it causes least entropy at this stage and allows us to move forward
> it's Tom's preferred ("least unfavorite") option.
>
> 2) Invent our own TristatedPredicate class (with a static method to
> generate
> one from a Guava Predicate)
>
> 3)  Invent our own PredicateThatThrows class (with a similar static
> method).
> Unfortunately due to the oddness of java's type mechanism it cannot be a
>
>  class ThrowablePredicate<I, T extends Exception> {
>    abstract boolean Apply(I in) throws T;
> }
>
>
It's not clear to me if the failure scenario always represents something
exceptional, but given these three options, I think I'd go with #2 or #3.
I'd avoid intentionally implementing a try-catch-rethrow, but I can't speak
to the scope here.
Just my 2 cents. (or perhaps 1.5)

--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130530/35ab8589/attachment.html