Add Java SDK error-handling best practices page - #5050
Merged
Conversation
Java was missing the error-handling page that Go, Python, .NET, and Ruby already have. Covers catching Exception (never Throwable/Error), wrapping checked exceptions with Workflow.wrap()/Activity.wrap(), reading a failure's cause chain, and centralizing failure conversion in a Worker Interceptor.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📖 Docs PR preview links
|
Duncanma
enabled auto-merge (squash)
August 7, 2026 19:45
lennessyy
approved these changes
Aug 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds
docs/develop/java/best-practices/error-handling.mdx— Java was the one major SDK missing the error-handling page that Go, Python, .NET, and Ruby already have.Closes #5013
Closes #4006
The page covers:
Exception, neverThrowableorError— with the reasoning (DestroyWorkflowThreadError,UnsupportedVersion) and a catch-decision order for Workflow/Update/Signal codecatch (Throwable t)swallow-all anti-pattern, spelled out with the three concrete failure modes it causesWorkflow.wrap()/Activity.wrap()instead of adding them to method signatures, including direct answers to "do I need to wrap what I throw" and "do I need to re-wrap after unwrapping"ActivityFailure→ChildWorkflowFailure→ApplicationFailure), including thegetMessage()vsgetOriginalMessage()gotcha and matching ongetType()instead ofinstanceofWorkerInterceptorAlso wires the page into
sidebars.jsand the best-practices index, and cross-links it from the cancellation page (the one spot #5013 called out as having an indirect, one-sentence mention of the catch-Throwable rule today).Notes to reviewers
Every code-level claim is verified against
sdk-javasource (CheckedExceptionWrapper, thefailure/*classes,DestroyWorkflowThreadError,UnsupportedVersion), the officialHelloExceptionandbookingsagasamples, and an internal best-practices writeup on Java error handling — not just the community forum post cited in #5013.Scope note: the source material I checked goes considerably deeper (retry classification by HTTP/gRPC status code, cross-attempt error-context accumulation via heartbeats, a generic exception↔
ApplicationFailureconverter pattern, full Saga mechanics). I kept those out of this page to match the depth of the sibling Go/.NET/Ruby pages and avoid duplicating/design-patterns/non-retryable-errorsand/design-patterns/saga-pattern— happy to split any of that into follow-up pages if you'd rather have it documented too.┆Attachments: EDU-6902 Add Java SDK error-handling best practices page