Skip to content

Conversation

@izeye
Copy link
Contributor

@izeye izeye commented Dec 28, 2025

This PR applies @CheckReturnValue to AssertJ Assert implementations similar to spring-projects/spring-boot#46766.

Signed-off-by: Johnny Lim <izeye@naver.com>
Copy link
Member

@shakuzen shakuzen left a comment

Choose a reason for hiding this comment

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

Looks good. Thanks. Should we add an ArchUnit rule as well to make sure we don't miss this going forward?

This commit also changes Assert implementations to comply with the rules.

Signed-off-by: Johnny Lim <izeye@naver.com>
Copy link
Contributor Author

@izeye izeye left a comment

Choose a reason for hiding this comment

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

@shakuzen Thanks for the feedback!

I tried to reuse the rules from Spring Boot and added more @CheckReturnValue annotations to comply with them in ef403a4.

There are some cases that I'm not sure if they are okay, which I commented below.

* @throws AssertionError if there is no matching observation
*/
@CheckReturnValue
public That hasObservationWithNameEqualTo(@Nullable String name) {
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 seems to read okay without that() and is also being used internally without that() which requires warning suppressions below.

I'm not sure if requiring that() is intentional, but it could be a breaking change for someone using it just for its presence check.

Copy link
Member

Choose a reason for hiding this comment

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

It does seem a bit awkward compared to other API. Perhaps we can work on migrating to something more consistent. For now, I think it's better to not have @CheckReturnValue here, since it can be used with or without using the return value.

* @throws AssertionError if the meter is not found
*/
@CheckReturnValue
public MeterAssert<?> meter(String meterName, Tag... tags) {
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 one and the following ones are similar cases with the above, but they seem to read incomplete.

Copy link
Member

Choose a reason for hiding this comment

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

I would keep the @CheckReturnValue here. If someone just wants to assert a meter with a name and tags exists, there are other ways to do that and they don't need to use this method.

@izeye
Copy link
Contributor Author

izeye commented Jan 1, 2026

For the build failure, I created #7044 to try to resolve it.

Copy link
Member

@shakuzen shakuzen left a comment

Choose a reason for hiding this comment

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

Happy New Year, Johnny! Thanks for updating things. I took a look and left some comments.

@@ -0,0 +1,59 @@
/*
* Copyright 2025 VMware, Inc.
Copy link
Member

Choose a reason for hiding this comment

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

Happy New Year! I guess this should be the first 2026 copyright year file

* @throws AssertionError if there is no matching observation
*/
@CheckReturnValue
public That hasObservationWithNameEqualTo(@Nullable String name) {
Copy link
Member

Choose a reason for hiding this comment

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

It does seem a bit awkward compared to other API. Perhaps we can work on migrating to something more consistent. For now, I think it's better to not have @CheckReturnValue here, since it can be used with or without using the return value.

* @throws AssertionError if the meter is not found
*/
@CheckReturnValue
public MeterAssert<?> meter(String meterName, Tag... tags) {
Copy link
Member

Choose a reason for hiding this comment

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

I would keep the @CheckReturnValue here. If someone just wants to assert a meter with a name and tags exists, there are other ways to do that and they don't need to use this method.

This commit also updates ArchUnit tests to cover them.

Signed-off-by: Johnny Lim <izeye@naver.com>
@izeye
Copy link
Contributor Author

izeye commented Jan 1, 2026

@shakuzen Happy New Year, Tommy!

I tried to apply your feedback in 2768cd9.

@shakuzen shakuzen merged commit 8a8ebbe into micrometer-metrics:main Jan 1, 2026
11 checks passed
@shakuzen shakuzen added this to the 1.17.0-M1 milestone Jan 1, 2026
@shakuzen shakuzen added enhancement A general enhancement module: micrometer-test An issue that is related to our TCK module: micrometer-observation-test labels Jan 1, 2026
@izeye izeye deleted the check-return-value branch January 1, 2026 11:46
allnightlong pushed a commit to allnightlong/micrometer that referenced this pull request Jan 19, 2026
…#7038)

* Apply @CheckReturnValue to Assert implementations

Signed-off-by: Johnny Lim <izeye@naver.com>

* Add ArchUnit tests

This commit also changes Assert implementations to comply with the rules.

Signed-off-by: Johnny Lim <izeye@naver.com>

* Use @CanIgnoreReturnValue for exceptional cases

This commit also updates ArchUnit tests to cover them.

Signed-off-by: Johnny Lim <izeye@naver.com>

---------

Signed-off-by: Johnny Lim <izeye@naver.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement A general enhancement module: micrometer-observation-test module: micrometer-test An issue that is related to our TCK

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants