On 26/10/2017 1:11 PM, John Rose wrote:
On Oct 25, 2017, at 8:07 PM, John Rose <john.r.r...@oracle.com> wrote:
On Oct 25, 2017, at 3:33 PM, Remi Forax <fo...@univ-mlv.fr
<mailto:fo...@univ-mlv.fr>> wrote:
getClasses() throws an exception but getAnnotations() skips unavailable
annotations.
that said, i'm not against throwing in this case.
I'm not against throwing either, but I think scrubbing (like annotations)
is a little better, because it is more robust about retaining partial results.
Aren't annotations a different situation because annotations are well
known to potentially not be available at runtime? A missing annotation
does not necessarily reflect an error in the runtime environment of an
application. Also AFAIK see from the jdk/java/lang/annotation/Missing/
test the throw/no-throw behaviour depends on exactly how the missing
annotation is used.
Partial results are important if you are just asking about one or two
classes and don't care about their other nestmates.
How do you know to only ask about "one or two classes"? Sorry I'm not
understanding the potential usecase here.If you've already identified
specific classes of interest then you can call getNestHost on them.
And even if H.getNestMembers() throws because of some missing N1,
we have to be careful to allow N2.getNestHost() to return H, if we can
validate that N2 points to H and vice versa. We don't want the validated
relation between N2 and H to be collateral damage to a failure of N1.
Absolutely not. The two queries would be completely unrelated in that
regard.
(If H goes missing there is nothing we can do with N1 and N2, except
to assign each to its own 1-nest. Which is OK with me.)
Then presumably we should do the same at the VM level instead of
allowing resolution related exceptions to propagate as currently
proposed? We could just throw IAE as we do if a nest-host validation
check fails. Though a case can still be made to allow VME's to pass through.
Though I still feel uncomfortable lying about the nest-host. I don't see
what usecases would be served by doing that. Other than informational
uses, I can't see a reason to actually identify the nest-host which
would not be impacted by lying about that identity. The only truly
useful query is for nestmate access and that doesn't need to expose the
identity of the nest-host and conservatively rejects access if anything
goes wrong.
Bottom line for my personal preferences:
- hasNestMateAccess: never throws, always returns true or false
- getNestHost(): throw if the host isn't there or else a membership
validation check fails
- getNestMembers(): throw if any nest member isn't there or a membership
validation check fails
Cheers,
David
