Skip to content

Conversation

@Pankraz76 Pankraz76 changed the title [MNG-8727] Prepare for Java 24 - Unnecessary throws [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover May 14, 2025
@Pankraz76 Pankraz76 marked this pull request as ready for review May 14, 2025 07:11
@Pankraz76
Copy link
Contributor Author

leftover...

image

thats why CPU out-smart human try&error, not the other way around, right?:
https://docs.openrewrite.org/recipes/staticanalysis/unnecessarythrows

@michael-o
Copy link
Member

Is this an unchecked exception?

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 14, 2025

sorry. No its Runtime. Does this make sense then?
This is kind of surprise.

image

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 14, 2025

Is this an unchecked exception?

https://stackoverflow.com/questions/824217/should-methods-that-throw-runtimeexception-indicate-it-in-method-signature

It is no longer obvious whether the exception has to be explicitly handled.
Having to add runtime exceptions in every method declaration would reduce a program's clarity.

@Override
public String metadataPath(ExecutorRequest.Builder executorRequest, String gav, String repositoryId)
throws ExecutorException {
public String metadataPath(ExecutorRequest.Builder executorRequest, String gav, String repositoryId) {
Copy link
Contributor

@gnodet gnodet May 14, 2025

Choose a reason for hiding this comment

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

The interface actually throws the exception. Given this is a public method, I'd rather keep it, as it may forbid derived classes to actually throw the exception in an overridden method.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, it's an unchecked exception, so the argument is moot.

@michael-o
Copy link
Member

Unchecked ones should be in Javadoc only, not on the signature.

@Pankraz76 Pankraz76 changed the title [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException to checked May 14, 2025
@Pankraz76
Copy link
Contributor Author

Unchecked

why guess, when able to make clear statement?

@Pankraz76
Copy link
Contributor Author

Unchecked ones should be in Javadoc only, not on the signature.

kindly request critics.

@Pankraz76 Pankraz76 changed the title [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException to checked [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException from Runtime- to Exception being stringent to ensure catch May 14, 2025
* @since 4.0.0
*/
@Experimental
public class ExecutorException extends RuntimeException {
Copy link
Contributor Author

@Pankraz76 Pankraz76 May 14, 2025

Choose a reason for hiding this comment

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

sounds important enough, being worth to give dedication and segregation.

@Pankraz76 Pankraz76 changed the title [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException from Runtime- to Exception being stringent to ensure catch [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException to Exception being stringent to ensure catch May 14, 2025
@Pankraz76 Pankraz76 changed the title [MNG-8727] Prepare for Java 24 - fix unnecessary throws leftover; promoting ExecutorException to Exception being stringent to ensure catch [MNG-8727] fix unnecessary throws leftover; promoting ExecutorException to Exception being stringent to ensure catch May 19, 2025
}
} catch (Exception e) {
throw new ExecutorException("Failed to dispose runtime created realms", e);
throw new RuntimeException(new ExecutorException("Failed to dispose runtime created realms", e));
Copy link
Contributor

Choose a reason for hiding this comment

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

this makes zero sense. First make the actual exception a checked exception, then wrap it into a (untyped) runtime exception.

Now there is no longer a ExecutorException thrown but a RuntimeException.

AI Slop.

@hgschmie
Copy link
Contributor

Replacing this exception is questionable and a change to the visible API for no value.

@hgschmie hgschmie closed this May 20, 2025
@jira-importer
Copy link

Resolve #9569

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.

5 participants