> On Mar 28, 2015, at 04:30, Mandy Chung <mandy.ch...@oracle.com> wrote: > > 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.
(Not really, the policy file format is not localized, why should its error msg be?) > > I think the application using this API should be handling the localization > not in the exception message. Suppose someone writes a GUI tool as a wrapper of this API. It is not easy for it to understand all exception messages and localize them. Throwable has a getLocalizedMessage() method, I'll see if I can use it. Actually, since this exception should always be generated inside JDK, shall I just remove all constructors from the public API? (Suppose there is an easy way to construct it without a public ctor). Is there such an example? > >> >>> 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). Great answer. I now think it should be unchecked. Thanks Max > > Mandy > >
