RFR: 8296408: Make the PCSCException public accessible

[Michael StJohns]

On 11/28/2022 1:10 PM, Sean Mullan wrote:
> 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.

Enums won't work here for all possible return codes from SCard*.   At 
least a few times I've gotten codes that indicate issues with the 
underlying driver or hardware than getting a well constrained set of 
error codes from SCard* calls that are all in winscard.h.

Ideally, a solution here should also be applicable to PKCS11 drivers.  
And I'm sure there are a few other abstracted services where getting 
access to the underlying C return code makes sense.

If I were doing this in a more general way, I'd probably define 
something like

package java.lang;

public interface ErrorCodeInterface {

     public long (int?) getErrorCode();

}

And have PKCS11Exception, PCSCException and any other exception that has 
gets thrown with the underlying code  (e.g. SQLException) implement that 
interface.

If we can't do that, then morphing CardException to use an error code 
and to be used in place of PCSCException for most of the internal code 
would seem to make the most sense.

Mike


>
> --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 
>>> <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
>>
>>