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 <[email protected]> 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
