RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable
Daniel Fuchs
daniel.fuchs at oracle.com
Thu Feb 14 20:39:17 UTC 2019
Hi Mandy,
On 14/02/19 20:20, Mandy Chung wrote:
> Fixing the implementation of Handler::isLoggable to return false
> if null to match the specification seems similar risk to changing
> the spec. What do you think?
How so? I mean - if no line of code is changed, then surely we can't
break existing code? But on second thought I believe I may
have made the wrong choice her. See below...
> In addition, logging tends to be gracious as it's a
> cross-cutting concern and not to disturb the application runtime
> until it's a runtime issue. So I think isLoggable accepting null
> may be by design.
I agree that returning false would be a much better implementation
than throwing NPE. StreamHandler already does that. The only
concrete implementation (in the JDK) of Handler that doesn't
return false is the memory handler.
> Handler.publish(LogRecord) specifies to ignore null record and
> the implementation calls Handler.isLoggable(record). If the spec
> is changed to throw NPE, Handler::publish will need to change
> too. This impacts all APIs that accept null LogRecord while
> assuming isLoggable(null) returns false.
That is a good point.
> I think normal logging purpose would pass non-null records
> otherwise this issue should have been reported long ago.
Well... That and the fact that FileHandler, ConsoleHandler,
and friends are all StreamHandler (and return false).
Maybe you're right - and changing the implementation
is the right thing to do.
Let me redo my fix and see if the JCK complains.
Thanks for the feedback!
best regards,
-- daniel
More information about the core-libs-dev
mailing list