Comments (5)
I now came up with something like:
public static void aaa() {
Failsafe.with(RetryPolicy.builder()
.withMaxRetries(1)
.handleIf((o, throwable) -> throwable instanceof AssertionError && (throwable.getMessage() == null
|| !throwable.getMessage().contains("ddd")))
.build())
.run(() -> {
System.out.println("aaa");
bbb();
});
}
But I do not know if that is the most elegant way to do that.
from failsafe.
I don't understand what behavior you're trying to achieve. You want aaa()
, in general, to retry some code if an AssertionError is thrown during the execution of that code.
But you don't want it to retry if a particular method that aaa()
calls, ddd()
, throws an AssertionError due to multiple failed attempts all throwing AssertionError.
Is the idea that an AssertionError thrown from ddd()
is somehow special, meaning that there's no need for aaa()
to handle it the way it would if it wasn't coming from a Failsafe call?
These are weird semantics, very non-modular. And trying handle AssertionErrors at all feels dangerous.
But assuming that's really what you want, then you could convert the AssertionError thrown by ddd()
to some other known exception or error to avoid it being handled by aaa()
, and then (if you want) convert it back to an AssertionError.
@SuppressWarnings("unchecked")
public static void aaa() {
try {
Failsafe.with(retryAssertionErrorOnce).run(() -> {
System.out.println("aaa");
bbb();
});
} catch (FailsafeException ex) {
if (ex.getCause() instanceof AssertionError) throw (AssertionError) ex.getCause();
throw ex;
}
}
public static void bbb() {
System.out.println("bbb");
ccc();
ddd();
}
public static void ccc() {
System.out.println("ccc");
}
@SuppressWarnings("unchecked")
public static void ddd() {
Failsafe.with(wrapAssertionError, retryAssertionErrorOnce).run(() -> {
System.out.println("ddd");
throw new AssertionError("ddd");
});
}
static RetryPolicy retryAssertionErrorOnce = RetryPolicy.builder()
.withMaxRetries(1)
.handle(AssertionError.class)
.build();
static Fallback wrapAssertionError =
Fallback.builderOfException(e -> new FailsafeException(e.getLastException()))
.handle(AssertionError.class)
.build();
public static void main(String[] args) {
MyClass.aaa();
MyClass.bbb();
}
This produces the output you were hoping for, but again, this all seems highly suspect to begin with.
from failsafe.
Thank you, I was not aware of the possibility which you have shown in your example.
What I was looking was a kind of "circuit breaker" for retries I guess.
Lets assume there are nested retries. It does not matter what they do for the example. If a retry fails in one of the nested retry methods then, depending on the concrete case, it might be useless if the outer retry methods perform a retry on failure, because it would start the inner retries all over again, but it would be useless.
That can be handled with different exception types, but I was looking for a more elegant and safe way. Like if a retry policy can be configured to signal outer retry methods not to retry if they catch this signal. I do not know the Failsafe framework so much, but maybe if it would then throw a "FailsafeDoNotRetryException", then the outer retry blocks would not attempt to retry but fail instantly.
I am not sure if that makes sense. If not, no need to waste your time on that. What I wanted to achieve I could do now.
from failsafe.
Related Issues (20)
- Add FailsafeExecutionException extending FailsafeException for wrapping Throwables in sync get HOT 1
- Make CircuitBreaker delay time mockable for testing HOT 6
- Support Java Modules HOT 1
- Add Failsafe to vertx-awesome HOT 1
- Result futures strongly retain supplying functions
- 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
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.