Now we are getting way off topic, but I would argue that a message that
contains no specific context information would still be a good message. There
is nothing wrong with a debug message of logger.debug(“User: {}, userId); as
this contains all the context information you need to determine where it
originated.
Generally it is quite a PITA to constantly have to code:
debug(“Performing action X in method foo in class “ + MyClass.class);
It is also more expensive since you are doing String concatenation whether you
want debug messages or not. Logging frameworks exist to a) make logging easier
and b) to separate generating the log events from what happens with them.
The other problem with using a simple debug() construct is that typically you
will have Application —> library1.method1
—>library1.method2—>library2.method1—>library3.method1—>debug msg which makes
it difficult to determine where the message originated if the message only
contains general information about the error. At least with the typical
conventions followed when using Loggers you will have a logger name that helps
identify where the error occurred even without the class, member and line
number information. But event then, those can be included in the log event if
the configuration says they should without having to change the code.
Ralph
> On Jun 10, 2016, at 9:09 AM, sebb <seb...@gmail.com> wrote:
>
> In any case, if the message String does not give sufficient context to
> be able to understand where the message originated, then arguably it's
> not a very good message.
>
> On 10 June 2016 at 16:34, Matt Sicker <boa...@gmail.com> wrote:
>> Oh, I didn't even notice the printStackTrace() part until now. Good point.
>>
>> On 10 June 2016 at 10:23, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>
>>> Matt, there is a big difference between printing the stack trace and
>>> walking it to find the info. printing it on every debug call would be
>>> insane.
>>>
>>> Ralph
>>>
>>>> On Jun 10, 2016, at 8:09 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>
>>>> Without Java 9, that's pretty much the only way to get the caller line
>>>> number and other metadata besides the caller class.
>>>>
>>>> On 10 June 2016 at 09:44, Jochen Wiedmann <jochen.wiedm...@gmail.com>
>>> wrote:
>>>>
>>>>> On Fri, Jun 10, 2016 at 4:02 PM, sebb <seb...@gmail.com> wrote:
>>>>>
>>>>>> Depends on what the implementation does.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> @Override
>>>>>> void debug( String message ){
>>>>>> new Throwable(message).printStackTrace();
>>>>>> }
>>>>>
>>>>> Even a dumb application developer like me would at least like to see a
>>>>> *bit* of performace. :-)
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boa...@gmail.com>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
