RFR: 8296408: Make the PCSCException public accessible

Michael StJohns mstjohns at comcast.net
Wed Nov 23 17:21:22 UTC 2022


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




More information about the security-dev mailing list