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.

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

Exception usage cleanup #1910

Merged
merged 9 commits into from
Nov 16, 2024

Conversation

cstamas
Copy link
Member

@cstamas cstamas commented Nov 14, 2024

This PR merely cleans up exception usage across Maven.

So make them checked and let compiler help you.

Made checked 3 exceptions:
* ModelBuilderEx
* ProjectBuilderEx
* ModelResolverEx

And it immediately uncovered an avalanche of problems.
@cstamas cstamas requested a review from gnodet November 14, 2024 12:13
@cstamas cstamas self-assigned this Nov 14, 2024
@cstamas cstamas changed the title There are exceptions tou want to deal with There are exceptions you want to deal with Nov 14, 2024
String groupId, String artifactId, String version, String tag, ThrowingSupplier<T, E> supplier)
throws E {
return ThrowingSupplierWrapper.process(
supplier, s -> cache.computeIfAbsent(groupId, artifactId, version, tag, s));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This is exactly the kind of boiler plate code I wanted to avoid using runtime exceptions.

Copy link
Member Author

Choose a reason for hiding this comment

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

most of this undone, we need to deal with one single exception only

Copy link
Member Author

@cstamas cstamas Nov 14, 2024

Choose a reason for hiding this comment

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

IMO, the latest push is quite sensible. Also, have to add "boilerplate code wanted to avoid" vs all the changes revealed just by the compiler, as exception went from unchecked to checked... which one is worth more for you?

It is same ex being thrown, so not need to have generic E
@cstamas cstamas added this to the 4.0.0-beta-6 milestone Nov 14, 2024
@gnodet
Copy link
Contributor

gnodet commented Nov 14, 2024

I really don't think that works. What if the ModelBuilder calls internally a service which throws an unchecked exception ? If the caller catches ModelBuilderException (which he would have to because that one is checked), then it may miss the unchecked exceptions. I don't really see a good justification for having only a few ones being unchecked or checked. That could work if there were real differences, such as transient issues (as in downloading and a network error happens), but most exceptions here are not of this kind.

@cstamas cstamas changed the title There are exceptions you want to deal with Exception usage cleanup Nov 15, 2024
@cstamas
Copy link
Member Author

cstamas commented Nov 15, 2024

Ok but @gnodet we need to pick up at least the bugfix from this PR, and consider maybe some others (you are catching ModelBuildingException while in fact ModelBuilderException is being thrown, etc).

@cstamas cstamas requested a review from gnodet November 16, 2024 17:31
@cstamas cstamas marked this pull request as ready for review November 16, 2024 17:31
@cstamas
Copy link
Member Author

cstamas commented Nov 16, 2024

Removed all the fluff, now really only the proper placement of exceptions are done (and at least two bugfixes where runtime ex "escaped" causing "internal maven error"). @gnodet pls review

@cstamas cstamas merged commit ab7d766 into apache:master Nov 16, 2024
13 checks passed
@cstamas cstamas deleted the there-are-ex-you-want-to-deal-with branch November 16, 2024 20:36
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