Obvious mistake:
logger.debug("This is fun", myFunObject::toString)
->
logger.debug("This is fun {}", myFunObject::toString)
Gary
On Thu, Jan 25, 2024, 11:55 AM Gary D. Gregory <ggreg...@apache.org> wrote:
> Hi All,
>
> I'd like to ask how to if we can devise advice around an issue I ran into
> this week.
>
> One of our test suites processes about 40K files of test fixtures. These
> inputs are parsed, processed, and asserted. This randomly fails on a call
> to Logger#debug(), randomly in that it happens usually once per build,
> somewhere in a logging call. But it usually fails with a call that looks
> like this:
>
> logger.debug("This is fun" + myFunObject);
>
> To simplify things, let's say that it turns out that after an underlying
> third party jar file version upgrade the call to myFunObject#toString() no
> longer returns Object#toString() but rather (again to simplify) the
> contents of the file that was parsed to create myFunObject. This toString()
> can be megabytes. The solution is obvious:
>
> logger.debug("This is fun", myFunObject::toString)
>
> And our CI builds no longer randomly fail since our default logging does
> not log at the debug level.
>
> A better solution could be:
>
> logger.debug("This is fun", () -> myFunObject.toString().substring(0, 100))
>
> where I still want _some_ information better than making my own toString()
> with System#identityHashCode(Object) or somesuch. Sure, .toString() is
> still called but it does not make it down into logging. In my case the OOME
> happened in myFunObject::toString so the substring() example would not have
> worked.
>
> My question is: Should we document some general advice on this pattern and
> what should the advice be? Would it make sense to have some features where
> we truncate/reject Strings above a threshold. And yes, calling
> myFunObject.toString() can still still get me in trouble.
>
> Gary
>
>
