Hi all, I'd like to discuss how TableNotFoundException (TNFE) is handled in some of our TableOperations methods. In several places, TNFE is neither declared nor thrown; instead it’s wrapped in an AccumuloException (AE). That pushes the burden onto calling code to discover the wrapping (by reading Javadoc or source) and then to handle it—both error-prone.
Obviously, the "right" solution is to have all applicable methods declare and throw TNFE directly. The blocker is that it’s a public-API change. This came up in the context of Accumulo PR #5540 [1], which refactors some TableOperationsImpl methods to use a single modifyProperties() call instead of multiple setProperty()/removeProperty() calls for atomicity. Since modifyProperties() doesn’t throw TNFE (but wraps it), I implemented a hacky workaround to unwrap and re-throw TNFE without changing the API. We should replace that workaround with a more permanent solution, so I’m opening this thread to discuss possible paths forward. Possible paths forward: 1. Backport the workaround into 2.1 Continue using the internal "unwrap AE -> TNFE" helper. Preserves the API and atomic benefits of modifyProperties(), but perpetuates the hacky code. 2. Break SemVer in 2.1 Change existing signatures so that modifyProperties(), setProperty(), etc., declare and throw TNFE directly. Clean and immediate, but violates SemVer and could break subclasses. 3. Deprecate & add replacements in 2.1 Mark the old methods @Deprecated and introduce new ones (e.g. mutateProperties()) with correct throws. Signals intent clearly, but adds API churn in a minor release. 4. Postpone public-API fixes until 3.1/4.0 - In 2.1: use the unwrap helper internally where needed. - In 3.1: deprecate the old methods and introduce properly-declared replacements. - In 4.0: remove or adjust the deprecated methods entirely. Any and all suggestions or feedback are welcome! [1] https://github.com/apache/accumulo/pull/5540
