On 13/06/14 12:10, Alan Bateman wrote:
On 13/06/2014 11:49, Michael McMahon wrote:
Okay. I can see the reasoning why supportedOptions should refer to
the platform rather than the process/instance
running. We could consider adding a sub-class of IOException for
permission related failures, but I'm not proposing
to do that here. For now, I'll just ensure that the error message
conveys the permission problem.
New webrev: http://cr.openjdk.java.net/~michaelm/8046588/webrev.2/
We also need to check for EPERM. Apparently, there are some codepaths
that use that instead
of EACCES.
For the test change then does it mean that a genuine failure will
cause the test to pass? I don't like change exception messages but I
just wonder if this test might have to resort to that to avoid passing
then there is another problem.
-Alan
To be honest, the test doesn't/(can't easily) check if a flow has been
created. So, in practice
a success return code doesn't prove that everything is working.
Exercising the code at least
is a basic smoke test. If we add a new exception then maybe we can
revisit, but I wanted
to get this change in ahead of the refactoring for modularity, becuase
this change
is needed for 8u20 and I don't want to hold that up and the refactoring
work will take some
time to review (it's a bit more complicated than expected).
Michael
