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.
Michael
