Checked Exceptions are not causing a failure event

[ferencbeutel4711]

Hi,

If a checked exception is thrown inside of a .item() - handler, it does not cause a failure event.

kotlin example

Uni.createFrom().item { throw Exception("checked exception") }
.onFailure(f -> println(f))

The above uni will never print the error (and pretty sure it will also never terminate, since this issue caused deadlocks in our application). If a RuntimeException is thrown, everything is fine.

[cescoffier]

Oh, I didn't know that about Kotlin.
For Java we have the "Unchecked" utility classes (https://smallrye.io/smallrye-mutiny/guides/unchecked), but if Kotlin can write such a code, we should be able to catch the thrown exception.

Any Kotlin user that knows the type of exception thrown in this case.

CC @jponge

[cescoffier]

Oh, BTW, the second line should be:

.onFailure().invoke(f -> println(f))

[jponge]

Ok so in Kotlin there is no notion of checked exception, and when you throw a java.lang.Exception (or any other checked exception) then MultiCreate#item will not handle them, only runtime exceptions.

This actually makes sense, because a supplier cannot throw a checked exception, so you can't write this in Java:

Multi<Integer> multi = Multi.createFrom().item(() -> {
  throw new Exception("boom");
});

...but this is fine for Kotlin which is more permissive here.

[jponge]

I'm tempted to say this is not a bug, because in Java you can't have this, this is specific to Kotlin and its laxer type checking wrt exception control flow.

[Ladicek]

Java has made "sneaky throws" really easy -- here's my favorite implementation:

public class SneakyThrow {
    private SneakyThrow() {
    }

    /**
     * This method can and should be used as part of a {@code throw} statement,
     * such as: {@code throw sneakyThrow(exception);}. It is guaranteed to never return normally,
     * and this style of usage makes sure that the Java compiler is aware of that.
     */
    @SuppressWarnings("unchecked")
    public static <E extends Throwable> RuntimeException sneakyThrow(Throwable e) throws E {
        throw (E) e;
    }
}

So you can have this in Java, really easily: throw sneakyThrow(new Exception("boom"));

[jponge]

Yes this is evilish @Ladicek 😆

[jponge]

So it's interesting, perhaps we need to catch better "just in case"

[jponge]

I'm looking into it.

[jponge]

I opened #534 to fix that.

[jponge]

Thanks @ferencbeutel4711 for reporting

[ferencbeutel4711]

hey guys, thank you so much for the quick fix!
We are using Mutiny via Quarkus, do you know how the usual release process works in that scenario?

[jponge]

It will be part of 0.17, we tend to release about once a month, then it's upgraded in Quarkus.