The problem of two exception handling

[liangyepianzhou]

Motivation

The exception here was handled twice, resulting in a null pointer exception.
And the position will be updated twice.

Modifications

Remove exceptionally in this case.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API: (yes / no)
• The schema: (yes / no / don't know)
• The default values of configurations: (yes / no)
• The wire protocol: (yes / no)
• The rest endpoints: (yes / no)
• The admin cli options: (yes / no)
• Anything that affects deployment: (yes / no / don't know)

Documentation

Check the box below and label this PR (if you have committer privilege).

Need to update docs?

• no-need-doc

[eolivelli]

Do you have any error/stacktrace to demonstrate your case?

[liangyepianzhou]

@eolivelli I encountered this problem when writing the offload of Transaction. Because there may be data that does not need to be transferred during offload, there may be holes when it is read out. In this regard, our processing is to return a NoSuchEntryException. Then we encountered this situation.Thanks to the help from @congbobo184 , this problem can be discovered.
#12449

[lhotari]

@merlimat Are you ok with this change?

[lhotari]

@congbobo184 This PR was reviewed and merged only by you. On the other hand, our contributing guidelines state that each PR must be approved by at least 2 Pulsar committers.
Was it intentional that you merged this PR?

[merlimat]

@liangyepianzhou @congbobo184 I think the PR solves the problem but it has a regression.

The exceptionally() clause is also use to catch exceptions that are being thrown in the whenComplete() part. For example we have a checkNotNull(...) part there.

Instead, I'd suggest to keep the exceptionally() part and convert the whenComplete() into thenAccept().

Eg:

CompletableFuture<Void> f;

doSomething()
    .thenAccept(res -> {
         //// Potentially throw exception
        f.complete(..);
    }).exceptionally(ex -> {
        f.completeExceptionally(ex);
       return null;
    });