On 18/03/15 18:03, Roger Riggs wrote:
Hi,
I think its up to loadConfiguration to handle (and specify) exceptions
in methods that it calls.
IAE is not your ordinary RuntimeException.
IAE in calling Properties.load is an issue for loadConfiguration to
handle; seems like it should
be turned into IOException in this case because it is because of a
malformed properties file.
Right. I was wondering about that too. Well if we catch it and
wrap it in IOException then it conforms to the current spec but
it will be a behavior change and so we still might need a CCC.
-- daniel
(I think IAE in Properties.load isn't the best choice of exception;
though I can see how
it can identify the argument (InputStream) is at fault; I'd have stuck
to IOException)
$.02, Roger
On 3/18/2015 11:16 AM, Daniel Fuchs wrote:
On 18/03/15 14:56, Jason Mehrens wrote:
Daniel,
It occurred to me after reading Brian's patch for
https://bugs.openjdk.java.net/browse/JDK-8075362 that the
LogManager.readConfiguration methods do not document NPE or IAE that
can be triggered by Properties.load. Do we need to file a bug just
against logging or should larger bug be filed to check all of the JDK
code that is calling Properies.load?
Hi Jason,
Thanks for the heads-up!
java.util.logging has a blanket statement concerning NPE, stating that
NPE will be thrown when parameters are null, unless null is explicitly
permitted.
I am not sure that we need to document every unchecked exception
that might happen down the road. That could end up with pretty
cluttered and obscure exception clauses.
That said the case where IAE is thrown seems straightforward, so
we might consider to add it to readConfiguration. Not sure whether
that would require a CCC or not.
Do others on this list have a strong opinion on this subject?
best regards,
-- daniel
Jason
