StatusRuntimeException without stacktrace - Android compatibility#11072
StatusRuntimeException without stacktrace - Android compatibility#11072ejona86 merged 2 commits intogrpc:masterfrom
Conversation
0ee9313 to
bd4c63e
Compare
|
The riddle of the missing API has been semi-resolved: #11762 . So it does look like we need to avoid the |
bd4c63e to
82e2bd5
Compare
ejona86
left a comment
There was a problem hiding this comment.
One Javadoc tweak needed. Otherwise looks good.
| * of the stack trace. | ||
| */ | ||
| @Internal | ||
| public static final StatusRuntimeException asRuntimeException(Status status, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Thank you! |
TBD, instead of #11066
Just demonstrating the idea, without comments in code for now.