LogManager.readConfiguration doesn't document IAE and NPE.

Daniel Fuchs daniel.fuchs at oracle.com
Wed Mar 18 17:15:23 UTC 2015


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
>>>
>>
>




More information about the core-libs-dev mailing list