Skip to content

Enable Error Prone check: FormatStringAnnotation#9512

Merged
findepi merged 4 commits intotrinodb:masterfrom
ksobolew:kudi/enable-error-prone-check-format-strings
Oct 6, 2021
Merged

Enable Error Prone check: FormatStringAnnotation#9512
findepi merged 4 commits intotrinodb:masterfrom
ksobolew:kudi/enable-error-prone-check-format-strings

Conversation

@ksobolew
Copy link
Contributor

@ksobolew ksobolew commented Oct 5, 2021

It mostly catches issues related to format strings in loggers, some in very old code. There's one suppression, where we intentionally add one more placeholder to the format string and Error Prone won't take it in any form.

It is ERROR by default. Will be removed once we enable all checks.

@cla-bot cla-bot bot added the cla-signed label Oct 5, 2021
@ksobolew ksobolew requested review from findepi and kokosing October 5, 2021 15:52
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we handle the logger based changes in a separate commit ? The one where exception should be first and followed by message

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I split it into four commits. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
LOG.info("Running import for %s%n%s", target, sql);
LOG.info("Running import for %s", target);
LOG.info("Query %s", sql);

Maybe

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be a more straightforward transformation, sure, but I think that if they are two separate logs then they may get separated in the output if there are concurrent threads. Perhaps this merging can be done in a separate commit, though.

@ksobolew ksobolew force-pushed the kudi/enable-error-prone-check-format-strings branch from 733e10d to 06a284d Compare October 6, 2021 07:40
Copy link
Member

@kokosing kokosing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's remove the e parameter now

            log.debug(e, "Error on doOpenTabl");

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice. What validates (does the checkstyle for) this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Error Prone, though somewhat by accident. It sees that there's no placeholder for the exception in the format string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you need to add @FormatString to airlift logger methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's already one, and that's how we can find all these issues here:

    @FormatMethod
    public void debug(String format, Object... args)
    {
        ...
    }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because of this line:

             log.error(format + ": %s", ObjectArrays.concat(args, t));

It kind of appends the Throwable as the last thing after the original format string. I tried to make it acceptable to Error Prone, or at least make the suppression more local, but couldn't. If you can think of a better way (or perhaps to get rid of it entirely), I'd be glad to fix it properly :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a comment. This is fine.

In some logging frameworks the exception to print is expected to be the
last format string argument, even though there's no placeholder for it.
In Airlift, though, this is different, and there's an explicit exception
parameter before the format string. Fortunately Error Prone can flag
this, although somewhat by accident (by seeing that there's no
placeholder for the exception parameter).
The logic here is that if we keep these as separate log invocations,
they may not be kept together in the log output if there are concurrent
threads also doing logging.

As a follow-up to the previous commit. Could be a more generic
transformation, probably.
@ksobolew ksobolew force-pushed the kudi/enable-error-prone-check-format-strings branch 2 times, most recently from c503e7f to 5141895 Compare October 6, 2021 08:36
This forces us to annotate all the places where we wrap or delegate
logs. There's one suppression, where we intentionally add one more
placeholder to the format string and Error Prone won't take it in any
form.

It is ERROR by default. Will be removed once we enable all checks.
@ksobolew ksobolew force-pushed the kudi/enable-error-prone-check-format-strings branch from 5141895 to 2010be8 Compare October 6, 2021 11:44
@findepi
Copy link
Member

findepi commented Oct 6, 2021

This is nice improvement, thanks!

fyi @trinodb/maintainers

@findepi findepi merged commit 788db6c into trinodb:master Oct 6, 2021
@ebyhr ebyhr added this to the 363 milestone Oct 7, 2021
@ksobolew ksobolew deleted the kudi/enable-error-prone-check-format-strings branch October 7, 2021 07:33
@kokosing
Copy link
Member

kokosing commented Oct 7, 2021

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

6 participants