Fallback: Exceptions are wrapped in FailsafeException

[failsafe-lib]

Fallback: Exceptions are wrapped in FailsafeException

[jhalterman]

A change was just made via issue #66 where only checked exceptions are wrapped in FailsafeException now. So in your example, MyCustomException will only be wrapped if it's a checked exception. Hopefully this helps.

Closing for now unless you're still hitting any problems related to this, then feel free to reopen.

[jhalterman]

@IevgenRagulin The drawback of making FailsafeException checked is that calling code would be forced to handle it, which is not great. An alternative would be to use the sneaky throws technique to forcefully throw checked exceptions, but that also has drawbacks. This is why Failsafe uses the current approach of wrapping checked exceptions in an unchecked FailsafeException, which is documented in the FailsafeExecutor javadocs.

[Tembrel]

It would have made the API much more complicated, too.

You could create your own utility method around the Failsafe call to unwrap your custom exception, e.g., something like this (uncompiled, untested):

public class CustomFailsafe {
    public static <R> R customGet(FailsafeExecutor<R> exec, CheckedSupplier<R> supplier) throws MyCustomException {
        try {
            return exec.get(supplier);
        } catch (FailsafeException ex) {
            Throwable cause = ex.getCause();
            if (cause instanceof MyCustomException)
                throw cause;
            throw ex;
        }
    } 
}

[IevgenRagulin]

@Tembrel love it, thank you, I think that's what I will do

[jhalterman]

Without doing a sneaky throws (which I'd prefer not to do), the only way for Failsafe to throw checked exceptions is to wrap them in FailsafeException. So for the sake of consistency, the intended behavior is to wrap all failures in FailsafeException, similar to how the executors framework wraps asynchronous failures in ExecutionException. Hopefully that works for you?

As for this behavior:

Only when I use a non-checked functional interface like Callable my custom exception is thrown unwrapped

...I'm not able to reproduce it (see the test in the commit below, which currently passes). Can you share a little test or reproducer?

[alexsanzdev]

Great! thanks!

[IevgenRagulin]

Hm... FailsafeException isn't a checked exception though. Is there a way to make Failsafe throw a checked exception?

[IevgenRagulin]

@jhalterman, forcing the code to handle the exception is exactly why I would like to use a forced exception. Changing the type of the exception that was thrown prior to retries feels unintuitive. If the code has thrown an SQLException, this is what I believe Failsafe should rethrow (it's probably ok if it's wrapped in a FailsafeException, but it would be great if at least the type - checked vs unchecked remained the same)

Overall though, amazing library, thank you for your work.

[jhalterman]

Thanks @IevgenRagulin. While some users might prefer to have checked exceptions thrown (ex: run(CheckedSupplier<T>) throws E), most users probably do not want to have to handle checked exceptions and/or aren't using them in their Failsafe executions. And unfortunately we had to choose one approach or the other, so we chose to wrap.