fredia commented on code in PR #24698:
URL: https://github.com/apache/flink/pull/24698#discussion_r1582504623
##########
flink-core-api/src/main/java/org/apache/flink/api/common/state/v2/StateFuture.java:
##########
@@ -49,7 +49,7 @@ public interface StateFuture<T> {
* @param action the action to perform before completing the returned
StateFuture.
* @return the new StateFuture.
*/
- StateFuture<Void> thenAccept(Consumer<? super T> action);
+ StateFuture<Void> thenAccept(ConsumerWithException<? super T, ? extends
Exception> action);
Review Comment:
Here we classify exceptions into two categories:
1. Exceptions in user code: Users are **not forced to** handle exceptions.
For example, users can handle various internal logic exceptions in callbacks,
or they can directly hand them over to `thenXXX()` without handling them, and
finally the exceptions will be thrown by the mailbox.
2. Exceptions in the asynchronous framework: directly let the job fail.
We don't want to be completely aligned with `CompletableFuture` because
`CompletableFuture` constraints must handle checked exceptions. For example,
the following code is not allowed in `CompletableFuture`, but is allowed in
`StateFuture`:
```Java
CompletableFuture<Void> future = new CompletableFuture<>();
future.thenAccept((v) -> {
throw new IOException("test"); // not allow
});
StateFutureImpl<Void> stateFuture = new StateFutureImpl<>(null,
exceptionHandler);
stateFuture.thenAccept(
(v) -> {
throw new IOException("test"); // allow
}
);
```
--
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: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
