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

Introduce @UnwrapException for Quarkus REST #42094

Merged
merged 1 commit into from
Jul 30, 2024
Merged

Conversation

geoand
Copy link
Contributor

@geoand geoand commented Jul 24, 2024

This allows users to configure exceptions
whose cause will be checked against exception mappers.

This capability already existed in Quarkus REST and was used to map some internal exceptions, but with the new annotation users can opt into the feature for whatever exceptions make sense for their use case.

@geoand geoand marked this pull request as ready for review July 24, 2024 06:54
@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@geoand geoand requested a review from gastaldi July 30, 2024 07:24
* Used to configure that an exception (or exceptions) should be unwrapped during exception handling.
* <p>
* Unwrapping means that when an {@link Exception} of the configured type is thrown and no
* {@code jakarta.ws.rs.ext.ExceptionMapper} exists,
Copy link
Member

Choose a reason for hiding this comment

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

This is a bit subtle. This unwrapping only happens when there's no registered mapper for the direct exception type?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct

Copy link
Member

Choose a reason for hiding this comment

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

Do you think this should be mentioned in the docs? (The guide, not just the javadoc)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is implied, no?

Copy link
Member

Choose a reason for hiding this comment

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

I did not find it implied, no. How I read it was that the minute we declare that an exception should be unwrapped, it will never match an exceptoin mapper.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you want to push an update with what you have in mind, I'm perfectly fine with that

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure how to phrase this in the docs, especially given that it's already a TIP followed by a NOTE, I feel like this succession of tips/notes should be turned into sub-sections :-/

Also, I'm now realising that it should probably be a warning (or error?) if we have both an exception mapper for T and an unwrap exception for T, no? In this case, the exception will never be unwrapped.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, I'm now realising that it should probably be a warning (or error?) if we have both an exception mapper for T and an unwrap exception for T, no? In this case, the exception will never be unwrapped.

Yeah, that can be a good follow-up

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'm not sure how to phrase this in the docs, especially given that it's already a TIP followed by a NOTE, I feel like this succession of tips/notes should be turned into sub-sections :-/

Yeah, very likely so.

docs/src/main/asciidoc/rest.adoc Outdated Show resolved Hide resolved
This allows users to configure exceptions
whose cause will be checked against exception mappers.

This capability already existed in Quarkus REST and was
used to map some internal exceptions, but with the new
annotation users can opt into the feature for whatever
exceptions make sense for their use case.

Closes: quarkusio#42089
@geoand geoand added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Jul 30, 2024
@quarkus-bot
Copy link

quarkus-bot bot commented Jul 30, 2024

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit f743fa4.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

@quarkus-bot
Copy link

quarkus-bot bot commented Jul 30, 2024

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit f743fa4.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.


Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 integration-tests/opentelemetry

io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest.testOTelInjections - History

  • Condition with Lambda expression in io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest was not fulfilled within 5 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest was not fulfilled within 5 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
	at io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest.reset(OpenTelemetryInjectionsTest.java:26)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)

⚙️ JVM Tests - JDK 21

📦 extensions/micrometer/deployment

io.quarkus.micrometer.deployment.binder.VertxTcpMetricsNoClientMetricsTest.testTcpMetricsWithoutClientMetrics - History

  • event executor terminated - java.util.concurrent.RejectedExecutionException
java.util.concurrent.RejectedExecutionException: event executor terminated
	at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:931)
	at io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:350)
	at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:343)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:833)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute0(SingleThreadEventExecutor.java:824)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:814)
	at io.vertx.core.impl.EventLoopExecutor.execute(EventLoopExecutor.java:35)

📦 integration-tests/opentelemetry

io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest.testOTelInjections - History

  • Condition with Lambda expression in io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest was not fulfilled within 5 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest was not fulfilled within 5 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
	at io.quarkus.it.opentelemetry.OpenTelemetryInjectionsTest.reset(OpenTelemetryInjectionsTest.java:26)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)

@geoand
Copy link
Contributor Author

geoand commented Jul 30, 2024

@FroMage I am going to merge this one and we can improve the docs in later PRs

@geoand geoand merged commit 53da33e into quarkusio:main Jul 30, 2024
49 checks passed
@quarkus-bot quarkus-bot bot added kind/enhancement New feature or request and removed triage/waiting-for-ci Ready to merge when CI successfully finishes labels Jul 30, 2024
@quarkus-bot quarkus-bot bot added this to the 3.14 - main milestone Jul 30, 2024
@geoand geoand deleted the #42089 branch July 30, 2024 15:12
Copy link

🙈 The PR is closed and the preview is expired.

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

Successfully merging this pull request may close these issues.

Customize list of exceptions to unwrap in resteasy-reactive
2 participants