RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

[Michael McMahon]

On 13/06/14 10:08, Chris Hegarty wrote:
>
>
> On 12/06/14 21:04, Michael McMahon wrote:
>> On 12/06/14 20:35, Alan Bateman wrote:
>>> On 12/06/2014 20:15, Michael McMahon wrote:
>>>>
>>>> It would be possible to change the error back, but what about
>>>> supportedOptions() - what should
>>>> that return? It doesn't seem right that it would include an option
>>>> that cannot be used and how do
>>>> we test it, if we can't tell whether the option is usable or not?
>>>>
>>>> Maybe it depends on how these privileges get configured, which is
>>>> something I'm looking into,
>>>> but if it's a case that specific user attributes need to be
>>>> configured on a system, then I'm not sure
>>>> we can count on that for our test systems.
>>> On platforms where the support option is supported then I would think
>>> that supportedOptions should include it, otherwise I could imagine
>>> users getting confused by the UOE.
>
> I think I agree with Alan here. If the platforms support the option, 
> then supportedOptions() should include it.
>
> >> For the tests then having them pass
>>> then the option is supported but can't be set due to lack of
>>> privileges seems reasonable to me. I guess it's a subjective and maybe
>>> others might have opinions on this.
>>>
>>> -Alan.
>>
>> But we don't have a distinction between the exception thrown from EACCES
>> and E not supported (or whatever it is).
>
> This is tricky, and adds a new dimension to socket option access, that 
> I didn't realize when this was added.
>
>> I don't think we want to start parsing error strings ....?
>
> Short of a new unchecked Exception type, then I think we can only 
> depend on the exception message ( not pretty! ).
>
> -Chris.
>

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.

Michael


>> Michael