RFR: 8296408: Make the PCSCException public accessible

[Xuelei Fan]

I’m not very sure what the update public APIs may look like.  If we are able to collect the possible card exception reasons, the design of CertPathValidatorException and CertPathValidatorException.BasicReason could be a reference.

Xuelei

> On Nov 23, 2022, at 9:21 AM, Michael StJohns <mstjohns at comcast.net> 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
> 
>