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