RFR: 8296408: Make the PCSCException public accessible

[Sean Mullan]

PCSCException is an internal API and is strongly encapsulated by default 
as of JDK 17 [1]. Applications should not be accessing it. Making an 
internal API public is not the solution.

Your suggestion to extend CardException with methods to provide/access 
the underlying error code seems more reasonable. Making the error code 
an enum, as Xuelei suggests also seems like it might be a cleaner approach.

--Sean

[1] https://openjdk.org/jeps/403


On 11/23/22 12:21 PM, Michael StJohns wrote:
> On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
>> On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns <mstjohns at comcast.net> wrote:
>>
>>> … CardException doesn't always pass through the details in a comprehensible way from the underlying cause, …
>> Does it sound like a cause that the public APIs are not sufficient? Alternatively, if it is possible to update the public APIs instead?
> 
> I once actually wondered why PCSCException existed, rather than using or
> extending CardException (e.g. besides simply to have a place to put all
> of the SCARD related error messages).
> 
> So you'd suggest extending CardException with a "getErrorCode()" method,
> a constructor that takes an error code in addition to a message, and a
> protected errorCode field.   Have PCSCException extend CardException and
> provide the current single argument constructor to create a
> CardException with an error message based on the error code?
> 
> One of the main reasons I would like a change like this is to deal with
> Window's semi-weird behavior when listing terminals and no terminals are
> found.  Right now I have to parse the returned message looking for
> "SCARD_E_SERVICE_STOPPED" and if that occurs, I return an empty list of
> terminals rather than continuing the throw.  There are a few of those
> codes where it makes sense to translate them into different behavior.
> 
> Mike
> 
> 
> 
> 
>>
>> Best,
>> Xuelei
>>
>>
>>> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
>>>
>>>
>>> Mailing list message from Michael StJohns ***@***.***> on security-dev ***@***.***>:
>>>
>>> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
>>>
>>> Hi - Sorry - just getting back to the list after a few days away.
>>>
>>> Given that this is a plugin provider for the PCSC access classes, and
>>> that CardException doesn't always pass through the details in a
>>> comprehensible way from the underlying cause, having access to
>>> PCSCException makes a lot of sense, and as far as I can tell is not a
>>> violation of the general plugin contract.
>>>
>>> To make it even more useful, adding a "public long getErrorCode()"
>>> method to PCSCException would help with the cases where a code that
>>> isn't actually an? SCard* related code causing the PCSC exception.
>>>
>>> But -
>>>
>>> Wouldn't this also require a change to the module definition file?
>>>
>>> Mike
>>>
>>> —
>>> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
>>> You are receiving this because you commented.
>>>
>> -------------
>>
>> PR: https://git.openjdk.org/jdk/pull/11012
> 
>