Expose native error codes and strings on private Exceptions?

[Sean Mullan]

On 11/30/24 8:11 PM, Michael StJohns wrote:
> Hi -
> 
> As Java has become more modularized and locked down, I've lost some easy 
> access to critical information in two places - PCSC and PKCS11.  I 
> haven't gone back to dealing with JDBC recently, but I think I might 
> have the same problem there.

It is a valid concern.

> To give you an example, java.smartcardio.CardException almost always 
> hassun.security.smartcardio.PCSCException as a "cause", and 
> PCSCException usually has a useful error code such as 
> SCARD_E_NO_READERS_AVAILABLE.  The problem is that I can't coerce the 
> Throwable from getCause() to PCSCException post JDK8 without going 
> through a number of hoops to open up various modules. Parsing the return 
> from getMessage() on the cause sort of works for PCSC stuf, but could 
> break in weird ways since those formats aren't specified.
> 
> Similar stories exist on the PKCS11 side of things.
> 
> 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