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 <mstjo...@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 <mstjo...@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 > >
