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

StatusRuntimeException without stacktrace - Android compatibility #11072

Merged
merged 2 commits into from
Dec 22, 2024

Conversation

panchenko
Copy link
Contributor

TBD, instead of #11066
Just demonstrating the idea, without comments in code for now.

@ejona86
Copy link
Member

ejona86 commented Dec 19, 2024

The riddle of the missing API has been semi-resolved: #11762 . So it does look like we need to avoid the boolean fillInStackTrace API. I like the approach here.

@panchenko panchenko force-pushed the without-stack-android-compat branch from bd4c63e to 82e2bd5 Compare December 19, 2024 21:49
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

One Javadoc tweak needed. Otherwise looks good.

api/src/main/java/io/grpc/InternalStatus.java Outdated Show resolved Hide resolved
@@ -42,8 +42,8 @@ private InternalStatus() {}
* of the stack trace.
*/
@Internal
public static final StatusRuntimeException asRuntimeException(Status status,
Copy link
Member

Choose a reason for hiding this comment

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

Should we tweak the name here to make it clear at call sites it is special? This PR is an improvement as-is, so it is up to you.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Btw, a related question: is it important to keep the old signature deprecated? That's only for situations if some application has "api" and "core" from different versions, which is most likely unsupported but possible theoretically.

Copy link
Member

Choose a reason for hiding this comment

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

I do consider it at times, especially with lesser-used artifacts like grpclb or xds. But it is pretty rare to depend on api and not core (transitively). grpc-context-only usages do happen, but I don't expect we'd be saving many people much headache. I suspect there are pretty frequent internal breakages between api and core that nobody considers/notices.

I see now we could have kept the old API and just chose which implementation based on fillInStackTrace. But it's also the sort of thing "why would anyone use this API except to disable the stack trace?"

Although... we don't actually need InternalStatusRuntimeException in api any more, because it is just using public API. This is good enough. Let's get it in to fix animalsniffer and anything else can be followup if we so desire.

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 19, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 19, 2024
@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 20, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 20, 2024
@ejona86 ejona86 merged commit ebe2b48 into grpc:master Dec 22, 2024
16 checks passed
@ejona86
Copy link
Member

ejona86 commented Dec 22, 2024

Thank you!

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.

3 participants