Expose native error codes and strings on private Exceptions?

[Michael StJohns]

Sorry - missed this before.

On 12/5/2024 4:50 PM, Sean Mullan wrote:
... clipped
>
> On 11/30/24 8:11 PM, Michael StJohns wrote:
>> I'm wondering if it would make sense to create a public interface 
>> that these closed off implementation or factory classes could 
>> implement that would allow for the retrieval of the native codes and 
>> messages without workarounds? E.g.  something like:
>>
>>
>> package java.lang; // or maybe java.util?
>>
>> public interface NativeException {
>>
>>     public Long getNativeErrorCode(); // Return null if not supported
>>
>>     public String getNativeErrorMessage(); // Return null if not 
>> supported
>>
>> }
>>
>>
>> Obviously, this is more general than just the security stuff, but 
>> that's where I've run into the related problems.
>
> I would be more inclined to add new standard Exception subclasses with 
> the specific information, in other words expose PCSSCException as a 
> public subclass of CardException and something similar on the PKCS11 
> side. However, the SmartCard/IO API is externally specified in JSR so 
> we would have to do an MR of that JSR.
>
> --Sean

PCSC, PKCS11 and JDBC are all plugin provider style things and I didn't 
think it made a lot of sense to twiddle all of the public APIs just for 
this.  But making a public interface available (and suggested) for the 
various private Exception classes that get passed as causes seemed to 
make a bit of sense as a way of avoiding that type of change.

If you were going to open up the SmartCard IO API I'd probably want to 
add a few other things:  ::cancel() methods for the various ::wait() 
methods; the ability to detect card reader plugin when provided by the 
native code.

Thanks - Mike