Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catch an exception due to incorrect pattern in Strings.format #87132

Merged
merged 4 commits into from
May 30, 2022
Merged

Catch an exception due to incorrect pattern in Strings.format #87132

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4662eb4
Catch an exception when formatting a string fails
pgomulka May 25, 2022
da69453
Update docs/changelog/87132.yaml
pgomulka May 25, 2022
a1a168f
assert and catch exception
pgomulka May 25, 2022
27dac27
Merge branch 'try_catch_in_format' of github.com:pgomulka/elasticsear…
pgomulka May 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/changelog/87132.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
pr: 87132
summary: Catch an exception when formatting a string fails
area: Infra/Logging
type: enhancement
issues: []
8 changes: 7 additions & 1 deletion libs/core/src/main/java/org/elasticsearch/core/Strings.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,8 +21,14 @@ public class Strings {
*
* This method calls {@link String#format(Locale, String, Object...)}
* with Locale.ROOT
* If format is incorrect the function will return format without populating
* its variable placeholders.
*/
public static String format(String format, Object... args) {
return String.format(Locale.ROOT, format, args);
try {
return String.format(Locale.ROOT, format, args);
} catch (Throwable e) {
Copy link
Member

Choose a reason for hiding this comment

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

Why throwable? This should probably be just Exception. Let OOM/etc propagate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exception is definitely better

return format;
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 not fail silently? We should somehow capture the actual problem, embedding it in the message. Also, add an assert here so that if we hit this in tests we can fail the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

how should we capture it? Maybe we should log it (with additional Strings's logger)

Copy link
Member

Choose a reason for hiding this comment

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

Yes, logging sounds good.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, not sure we can do logging, because this is in the core lib? It doesn't have any deps. Perhaps we could embed it in the message?

Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds like a great idea, return "Error processing logging message: " + format, then the logger will log it.

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 am not sure.. This would be a good solution if we only use this in logging (we do, but the method is in core with no indication that this is only for logging).
I wonder if just returning the original pattern is not good enough. This is what log4j is doing when a pattern has more place holders.
I wonder if we could rather just try to use some static analysis to detect this
https://rules.sonarsource.com/java/RSPEC-2275
this looks promising but would have to be adopted to our needs

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm OK with leaving it as is if it matches what log4j does.

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 raised an issue to look for static analysis solution this #87166

}
}
}