refactor(engine): give AtomicNodeTooLargeException its own message factory#359
Merged
Merged
Conversation
…ctory The too-large diagnostic was built by a private LayoutCompiler.atomicTooLarge helper. Move the message construction onto a static AtomicNodeTooLargeException.forNode(path, outerHeight, pageHeight) factory so the exception owns its own message, and have the three throw sites call it directly. Byte-identical message; this also lets a future extracted collaborator throw the same exception without reaching into LayoutCompiler.
893583c to
ab962b3
Compare
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.
Why
The "node too large for a full page" diagnostic was assembled by a private
LayoutCompiler.atomicTooLarge(path, outerHeight, pageHeight)helper. The messagebelongs with the exception that carries it, and keeping it on
LayoutCompilerblocks anycollaborator extracted out of the compiler from throwing the same exception (it can't reach
a private helper) — the first step of continuing the
LayoutCompilerbreakdown.What
AtomicNodeTooLargeException.forNode(path, outerHeight, pageHeight)factorythat builds the diagnostic (measurements only, no user document content).
LayoutCompiler(compileSplittableLeaf×2,admitAtomicBlock)now call
AtomicNodeTooLargeException.forNode(...); the privateatomicTooLargehelper isremoved.
Tests
./mvnw -f aggregator/pom.xml verify -pl :graph-compose-qa -am— full compile + javadocgate + the qa visual/parity byte-identity suite (643): green. The exception type and message
are unchanged, so the too-large regression tests (
PageCapacityToleranceDemoTest,PaginationEdgeCaseTest) pass as before.Byte-identical — same exception, same message string. The
forNodefactory is a new publicmethod on an already-public exception (an addition, not a break; japicmp is report-only for 2.0).