LuciferYang opened a new pull request, #9638:
URL: https://github.com/apache/paimon/pull/9638
### Purpose
close #9637
`RESTTokenFileIO.fileIO()` is declared `throws IOException` and then
converted the one it gets into an unchecked wrapper:
```java
try {
fileIO = FileIO.get(path, context);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
```
So a data token that cannot produce an inner FileIO surfaced as
`UncheckedIOException` from whichever FileIO call triggered the lazy creation,
past every caller written for the declared signature. Two of those live outside
paimon-common and can never run as things stand:
```java
// paimon-lance LanceUtils, and the same shape in paimon-vortex VortexUtils
try {
fileIO = ((RESTTokenFileIO) fileIO).fileIO();
} catch (IOException e) {
throw new RuntimeException("Can't get fileIO from RESTTokenFileIO", e);
}
```
Letting the `IOException` through is all this needs. The signature does not
change, so no caller has to, and the two above start reporting what they were
written to report. The cache is keyed by `RESTToken`, so this path runs again
on every token refresh rather than once at startup.
### Tests
`RESTTokenFileIOTest.testFileIOCreationFailureSurfacesAsCheckedIOException`
builds a `RESTTokenFileIO` over a scheme no loader can serve, with a unique
token so the static token-keyed cache cannot hand back another test's delegate,
and asserts that `exists` fails with an `IOException`.
Against the unfixed code that assertion fails on the type: what comes out is
`java.io.UncheckedIOException` wrapping an `UnsupportedSchemeException`.
`mvn -pl paimon-common -Dtest=RESTTokenFileIOTest test` on JDK 8: 5 tests, 0
failures. `spotless:check` and `checkstyle:check` on paimon-common are clean.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
