On 14 October 2015 at 12:20, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
> On 14/10/15 07:21, Mandy Chung wrote:
>> Several log methods throws NPE if the level is legible and the parameter
>> is null. E.g.
>> * @throws NullPointerException if {@code level} is {@code null}, or if the
>> level
>> * is loggable and {@code msgSupplier} is {@code null}.
>>
>> Should it throw NPE if the input parameter is null regardless of whether
>> the level is loggable?
>
>
> Yes probably. The reason it is like that is that it mimics
> what java.util.logging.Logger does (at least for message suppliers), but
> it is probably not a good idea to propagate this bad practice.
>
> I will change System.Logger spec to mandate to always throw NPE
> if Supplier<String> is null - and ensure that the implementations
> we have follow the spec.
I believe the desire in logging is to a sensible degree write
defensively to avoid getting an exception due to logging which
obscures the actual error.
Thus, log(level, msg) should accept a null message (but not a null level)
But, log(level, supplier) should not accept a null supplier or level
The Javadoc for 'System.Logger' starts with "The minimum set of
methods that a logger returned by..." which isn't a good description
of the interface.
I have a major concern that the class names 'Logger' and 'Level'
duplicate those of java.util.logging. While they are inner classes as
opposed to top level classes, both IntelliJ and Eclipse will find the
inner class and top level class when typing "Logger". This will no
doubt cause many users to import the wrong one. I propose that these
classes are renamed to avoid this problem. The simplest would be to
change them from inner classes to top level classes "System.Logger" ->
"SystemLogger". Alternatively, they could stay as inner classes and be
prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" ->
"System.BasicLogger".
Stephen
