refactor: make the onFailure to be typed when we use onFailure(RuntimeException.class)

[hadadil]

When I am using mutiny many times I would like to handle a given type of Exception nicelly to recover or convert the exception.

onFailure(SomeException.class)
   .transform(someException -> {
        LOGGER.info("some exception occured with field: {}", someException.someSpecialField);
        return new SomeElseExecption(someException.someSpecialField, someException);
    });

in this case the someException is type of SomeException so we can operate on this exception type safe and not as Throwable anymore.
in the past I have to do something like this

onFailure(SomeException.class)
   .transform(throwable -> {
        if (throwable instanceof SomeException someException) {
            LOGGER.info("some exception occured with field: {}", someException.someSpecialField);
            return new SomeElseExecption(someException.someSpecialField, someException);
        }
       // this is impossible, but I still need to do there something ?!
    });

[codecov]

Codecov Report

Attention: Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.90%. Comparing base (c55bb92) to head (7ac49be).
Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
...mallrye/mutiny/operators/uni/UniOnItemConsume.java	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1848      +/-   ##
============================================
+ Coverage     88.89%   88.90%   +0.01%     
+ Complexity     3062     3058       -4     
============================================
  Files           409      409              
  Lines         13029    13033       +4     
  Branches       1642     1642              
============================================
+ Hits          11582    11587       +5     
+ Misses          821      817       -4     
- Partials        626      629       +3     

Files with missing lines	Coverage Δ
...entation/src/main/java/io/smallrye/mutiny/Uni.java	90.90% <ø> (ø)
...n/java/io/smallrye/mutiny/groups/UniOnFailure.java	94.44% <100.00%> (+0.15%)	⬆️
...main/java/io/smallrye/mutiny/groups/UniOnItem.java	100.00% <ø> (ø)
...smallrye/mutiny/helpers/spies/UniOnFailureSpy.java	100.00% <ø> (ø)
...java/io/smallrye/mutiny/operators/AbstractUni.java	90.00% <100.00%> (ø)
...lrye/mutiny/operators/uni/UniOnFailureFlatMap.java	80.43% <100.00%> (+0.43%)	⬆️
...ye/mutiny/operators/uni/UniOnFailureTransform.java	93.33% <100.00%> (+0.22%)	⬆️
...mallrye/mutiny/operators/uni/UniOnItemConsume.java	89.18% <66.66%> (+0.30%)	⬆️

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jponge]

Not a review: I would use refactor!: xyz as a commit message, because it's a refactoring with breaking changes.

[hadadil]

Not a review: I would use refactor!: xyz as a commit message, because it's a refactoring with breaking changes.

good point. updated.
hopefully as I just only changed internal stuff this still be fine to go with it, but let's see.

[jponge]

Thanks a lot for looking into this, this is something we could have done better in the early days of Mutiny since onFailure with a guard should indeed have a more precise type in the next action.

That being said this introduces binary breaking changes, so I'd like to wait a bit before we decide to go ahead with this PR. This might land in a major release in a few months instead.

I will also ping colleagues for reviews / opinions.

[jponge]

Overall I would rename the TT parametric type to E (for error).

[jponge]

You should add more unit tests to show the failure type specialization in the API, especially with all the impacted groups / operators.

[hadadil]

I addressed your comments and also I have added few tests to cover the touched methods.
let me know if you think I missed anything.

[jponge]

@ozangunalp @cescoffier I've asked for review, but note that there is no rush for this PR. We should eventually consider it for Mutiny 3 I think due to the presence of binary breaking changes (source-level should be fine, but I've asked @hadadil to increase test coverage here so we see more of the new usage)

[cescoffier]

I like the idea, and yes, we should have done that since day 1 (my fault).

[prakashelango]

Do we have any road map for mutiny ex: 3.x? similar to quarkus wanna see this breaking change soon.

[jponge]

We don't have roadmap yet, but we'll sort it by mid-June I think.

Meanwhile you can always apply the patch on your own build of Mutiny (not ideal I know, but...)