On 3/26/15 9:18 PM, Wang Weijun wrote:
JarSignerException.ErrorCode - do you expect the caller will want
to process error handling differently with different type of error?
I wonder if the error message would be good enough wrapping the
Throwable cause.
Yes, I agree a ctor with arguments (message, cause) is enough. The type of
cause is actually equivalent to the ErrorCode. The new message argument should
be localized.
Generally, JDK tool emitted messages are localized but exception messages
are not localized. I notice that some security exception messages are
localized (sun/security/util/Resources.java and
sun/security/util/AuthResources.java)
that may make sense for example parsing policy file.
I think the application using this API should be handling the localization
not in the exception message.
Should JarSignerException be an unchecked exception?
In traditional Java style, it should be checked. Normally unchecked exception
should not be expected if running normally, but here we will see TSA connection
error, algorithm name error, etc.
In fact I originally suggested unchecked exception, but my main reason is that
a checked permission is not friendly with lambda and a little old fashioned.
This exception is thrown at error cases. It looks like when the
exception is raised, there is no action the caller can do other
than outputting an error message and exit, right? Then
unchecked exception would be more appropriate (see Effective Java
item 59).
Mandy
