The use-case:
an exception occurs during CompletableFuture chain
none of exceptionally, whenComplete or handle method is attached to that CompletableFuture chain
The result:
The exception is never caught and there's no tracking/log of it. Which in case of Async systems is 1) undesirable and 2) an indicator for hard and hidden problems (such as NPE, Runtime Exc, etc.) to spot.
The question:
Is it feasible to implement CompletableFuture.UncaughtExceptionHandler mechanism by analogy / in a similar manner with java.lang.Thread.UncaughtExceptionHandler? The idea is to provide [default] uncaught exception handler/completion to be called if the CompletableFuture chain does not have java.util.concurrent.CompletableFuture.UniExceptionally Completion attached.
The simple answer is: no.
However, someone posted an ugly hack to get similar behavior in another thread:
How to handle uncaught exceptions from CompletableFuture.runAsync
I for one escape this problem by using ReactiveX (http://reactivex.io), but that choice might be beyond your control. In that case, you could consider creating a wrapped class for CompletableFuture that always registers an exception handler behind the scenes, so you don't have to explicitely call exceptionally(..) any more. But again, this is just a work-around.
Related
If an Eventhandler that updates a projection in the read model throws an exception, this is a bad thing.
In this case I would like do differentiate between "permanent" and "non permanent" exceptions.
With "permanent" Exceptions I mean Exceptions, that most likely are caused by wrong code and will be thrown again and again if I try to retry handling the event on this event handler.
With "non permanent" Exceptions I mean "temporary" e.g. Io/Network/... related Exceptions that are not caused by wrong code and which make sense to retry until the event is eventually handled successfully.
While I can come up with examples I would consider the one or the other (like InvalidOperation or IOException) is there any list or recommendation which exception (in this case in the asp.net 5 stack) should be considered what?
One option is to add a retry or circuit breaker policy using Polly that automatically retries all the exceptions (per read-model) and after X retries, do either disable the specific read projection that failed or the entire read-model.
The question is what you want to happen when the read model can't be updated. Do you:
Shut down the specific projection and allow the rest to be updated?
Shut down the entire read model
Or enter a "I am out of sync" mode?
I think this all depends on how you have constructed your read model and what your business case is.
A few of the articles / answers I read on SEH (Structured Exception Handling) consider it to be 'asynchronous'.
It is my understanding that the whole handling part of these exceptions occurs on the thread that raised them (on the CPU level). Basically, once an exception occurs, the excecution 'jumps' to OS code that iterates on the current thread exception handler list.
So is my understanding correct? What exactly is asynchronous about SEH?
In the synchronous model of exception handling, exceptions are always explicitly thrown; an actual throw statement has to occur in the source code, at a known and clearly defined point in the instruction stream so the compiler has knowledge of when exceptions can occur (which also means it can optimize out exception handling code if it can prove no exceptions can occur).
SEH is about CPU triggered exceptions, things that the code itself didn't realize could happen, but were raised "out of band" so to speak. It's asynchronous in that the exception is injected into code that was unaware it could even happen, much in the same way signal handlers can be run in the main thread, interrupting whatever was actually happening at the time the signal was received.
SEH can be thought of much like temporarily registered signal handlers, where the exceptional conditions are signals, the __try blocks define where the handler is in effect, and the __except and __finally blocks are the handlers if the "signal" is received.
My activities throw exceptions from time to time during the execution, so I've implemented the Faulted methods of Activity<TInstance> to handle that, discarding the changes made in the Execute method. I thought that there's some wiring underneath in Automatonymous that makes it so that the Faulted method executes when the Execute method throws an exception and then calls the Faulted methods for the activities that were executed already. It turns out that there's no such thing, as my Faulted methods are never executed.
Should I call those myself in a try/catch block instead? I could produce the BehaviorExceptionContextProxy based on BehaviorContext and the exception thrown. The only next Behavior I could pass would be the one inserted into that Activity's Execute method, but logically that means I'm compensating in the wrong direction as that next Behavior is actually to be executed after this one succeeds, so I'd compensate too much.
I also tried to use the Catch in the state machine, which does handle the exception, however, I couldn't find any way to start the execution of the compensation flow for the activity that failed when I only have the ExceptionActivityBinder present.
Is there any good way to trigger the compensation flow of the activities?
An activity within a state machine (using Automatonymous) is much different than an activity within Courier. Unfortunately, they both have the same name, which can create confusion.
When an activity throws an exception, the Faulted method of the next activity in the behavior is called. If that method is a regular activity method (such as .Then, .Publish, etc.) it is skipped, since the Faulted method of those activities just calls the next activity in the behavior.
A Catch activity, however, can be used to catch the exception and execute a rescue behavior (which is a sequence of activities).
Either way, the Faulted method of the activity which throws an exception within the Execute method is not called. So yes, you should use a try/catch, but allow the exception to flow back out of the Execute method so that the behavior handles it properly.
I've been playing around with Netflix OSS Hystrix and I am now exploring different configurations and possibilities to include it in my project. Among other things, my application needs to do network calls in HystrixCommand.getFallBack() ...
Now, I read that it is best-practice NOT to do network calls there and instead provide some generic answer (see Hystrix Wiki) and if it is really necessary to do this, one should use HystrixCommand or HystrixObservableCommand.
My question is, if I use HystrixCommand should I invoke it e.g., with HystrixCommand.run() or HysrixCommand.queue() or some other option?
Also, in my logs I've noticed that getFallBack() can have different calling threads (e.g., Hystrix-Timer, I guess this depends who interrupted the run method). Here I would like to know how shell calling HystrixCommand.run() from the fallback affect my performance, since the calling thread will be alive and blocked until that command finishes?
EDIT: With the fresh eyes on the problem, I am now thinking that the "generic answer" (mentioned above) could be some form of Promise i.e., CompletableFuture<T> in Java terminology. So returning the promise from the HystrixCommand.run() would allow the calling thread (Hystrix internal) to return immediately, thus releasing it. However now I am stuck on implementing this behavior. Any ideas?
Thanks a lot for any help!
Use a HystrixCommand's execute method. Example:
#Override
protected YourReturnType getFallback() {
return new MyHystrixFallbackCommand().execute();
}
If you want to work with async "promises" then you should probably implement a HystrixObservableCommand.
When we call fsm.process_event('eventname');
is there a way to return true if the transition occured and false if "no_transition" was called or an exception occurred?
Thanks
Seeing as no one has answered so far I'll post my quite humble suggestion. You could try calling the current_state() method before and after calling fsm.process_event() and compare the results. This however would not cover the case of self transitions or internal transitions and is not something I would use if there are other alternatives (its a hack at best).
If you are trying to catch the case of an event not being handled by any state and just propagating through you could add one more bottom layer superstate which reports events that reach it (i.e. are ignored by all states they propagated through).
I have had situations where I needed to know if some event actually did something and when it did it (maybe it was deferred first and then executed). In that case I made my MSM post "ACK" messages to an outside queue, I'm not sure if this applies to your problem.
In my humble knowledge interrupts and state machines don't mix very well, I usually either simply swallow them or try and turn them into some event depending on the context. You should never allow you sates (the underlying function objects) to throw.