Skip to content

Conversation

GNL10
Copy link
Contributor

@GNL10 GNL10 commented Sep 2, 2025

No description provided.

@GNL10
Copy link
Contributor Author

GNL10 commented Sep 2, 2025

I made sure that I covered all the usages of these constructors by forcing compilation errors (normal compilation, compiling the UTs as well).
If there are pieces of code that could use these constructors but are not getting compiled with these commands (and are not being tested), I probably missed them.

Copy link

sonarqubecloud bot commented Sep 3, 2025

Copy link
Owner

@danmar danmar left a comment

Choose a reason for hiding this comment

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

I don't really see the advantage with this reordering. It looks rather dangerous. I don't understand how you made sure that all ids and messages are reordered - you said something about a compiler error.

I appreciate you try to fix something here.. would you like some suggestions for bugs that you can look at?

@GNL10
Copy link
Contributor Author

GNL10 commented Sep 11, 2025

I was just fixing the TODO that is in the code. The main advantage is simply to give consistency to the order of the msg and id fields in the multiple constructors of ErrorMessage.
After this MR they will all have the same order.

Regarding the compiler error, I was just mentioning that in order to find all applicable instances of the constructor, I forced a compiler error to happen specifically in these constructors that I updated. Then I updated the parameters in all of them and then I reverted the change that triggered the compiler error.

Sure I can take suggestions for bugs to look at!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants