Comments (9)
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.
from failsafe.
@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.
from failsafe.
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;
}
}
}
from failsafe.
@Tembrel love it, thank you, I think that's what I will do
from failsafe.
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?
from failsafe.
Great! thanks!
from failsafe.
Hm... FailsafeException isn't a checked exception though. Is there a way to make Failsafe throw a checked exception?
from failsafe.
@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.
from failsafe.
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.
from failsafe.
Related Issues (20)
- Why does CheckedPredicate exist? HOT 2
- Also add note about default maxRetries of 3 to maxDuration section of the documentation HOT 7
- Bulkhead policy may drop requests when maxWaitTime is specified HOT 8
- Guidance around CheckedPredicate HOT 2
- Time based error limiter policy
- [Question]Can withBackoff and withDelay be used at the same time? HOT 2
- RetryPolicy handleIf not working with DynamoDbException in predicate HOT 4
- Having a context object in the run(...) and get(...) methods HOT 7
- dev.failsafe.Functions.* do not propagate toString to the wrapped object
- [Question] Is it possible to have multiple Fallback policies in one Failsafe executor? HOT 4
- [question] how to use failsafe with kotlin
- Feature Request: Integrate / add support for Lunar Proxy (backend policy) HOT 1
- Why recommend CircuitBreaker before Retry? HOT 1
- CircuitBreaker stays in OPEN even after DELAY time HOT 1
- Nested retries, how to prevent duplicate retrying? HOT 5
- FailsafeExecutor.compose and .with(Executor) have surprising composition behavior
- Provide BOM with all failsafe artifacts for better dependency management
- Failsafe okhttp integration causes issues with BearerAuth and outdated tokens
- CircuitBreakerBuilder withSuccessThreshold documentation whoopsy HOT 1
- [Question] Is it possible to override the "maxRetries" and "delay" of retry policy at runtime? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from failsafe.