What to do after ServicesExceptionNotHandled?
- I'm building a base workflow engine for a couple workflows.
I know a persistence service , for instance, can raise ServiceExceptionNotHandled, and I can catch it listening in the engine.
My question is, if this happens, what happens with the workflow instance that triggered the operation that raised the Exception? If the ServicesExceptionNotHandled condition was something temporal, can I just suspend the workflow and resume ? Or the instance is in a useless state, and I should just cancel it and discard it?
Thanks.
Answers
- Actually, I just remembered that when an exception is thrown from the service layer the WFI will be aborted. So my advice above is still the same except that you should get your retry logic for free as the WFI should be aborted and you could later call Load on it to have it execute starting at the last persistence point that it had.
If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
My blog: http://www.RyanVice.net/- Marked As Answer byGuillermo Martelli Wednesday, November 04, 2009 1:11 PM
All Replies
- Hi, Guillermo
->"My question is, if this happens, what happens with the workflow instance that triggered the operation that raised the Exception?"
->"If the ServicesExceptionNotHandled condition was something temporal, can I just suspend the workflow and resume ? Or the instance is in a useless state, and I should just cancel it and discard it?"
Event WorkflowRuntime.ServiceExceptionNotHandled is raised when the service-owned thread throws an exception. A service that is derived from the WorkflowRuntimeService class can call the RaiseServicesExceptionNotHandledEvent() method to inform subscribers to the ServicesExceptionNotHandled event that an exception occurred during its execution, and that it was unable to handle this exception. The out-of-box services raise this event in such conditions. The host application can subscribe to this event to implement a recovery mechanism. The event argument that is associated with this event is ServicesExceptionNotHandledEventArgs .
For more info, please check:
http://msdn.microsoft.com/en-us/library/aa663362.aspx
Regards
Microsoft Online Community Support - Andrew,
Like I said, I know a service, such as a custom persistence service, or the built in service, can raise that exception. I subscribe to that event, and get notified, ok.
What I dont understand is what I´m supposed to do about the recovery mechanism. Can I just retry what caused the exception? (say, the database was down and that triggered the event). How do I make the workflow retry?
Would just Suspend/Resume be enough for it to retry whatever caused the service to fail? If I was inside some nested aec (say, a While, or a replicator) will it pick up from where it failed? I found no information at all about what happens with the workflow when something errors out. What is supposed to be the usual recovery mechanism for a running workflow?
All I found here was some discussions about workflow aborted, and I´m not sure the same applies to ServicesExceptionNotHandled (as in, I should either discard the instance, start hacking away at the persistence service or perhaps build my own runtime mechanism to handle possible errors and retries).
Thanks.
The default error handling in WF 3.5 is a bit of a pain point IMHO. Basically when an unhandled exception occurs in a workflow that WFI (WF instance) will be terminated and can't be restarted. To deal with this the model is that you use fault handlers in your WF definitions in the same way you would use exception hanlders in a non-WF program.
For the service layer exceptions there are a lot of possibilities on what could go wrong and how it should be dealt with. Ideally your services would be coded in such a way that they wouldn't let unhandled exceptions happen and you as a local service author would add whatever logic is appropriate for that particular service. Maybe you want to retry, maybe you want to log it and suspend the WFI. For core services (WF persistence, scheduler, ect...) again it's your call. You can sub-class any of these services and provide overloaded implementations that would preform retrys or whatever you'd like to happen.
Once an exception makes it to ServicesExceptionNotHandled, IMO it's too late to really do anything very useful as far as recovery is concerned because as I mentioned above the appropriate place for recovery\retry logic is in the service classes. Once an exception makes it to ServicesExceptionNotHandled I'd just log it and possibly suspend the WFI (assuming you know which one was invovled).
In our system we implemented it so that it aborts on unhandled exceptions in the WFIs and we persist after every activity. This effectivily allows us to retry from where the exception happened but of course come with a performance hit. But it also provides the benifit that we don't have to worry about fault handling or compensation.
If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
My blog: http://www.RyanVice.net/- Actually, I just remembered that when an exception is thrown from the service layer the WFI will be aborted. So my advice above is still the same except that you should get your retry logic for free as the WFI should be aborted and you could later call Load on it to have it execute starting at the last persistence point that it had.
If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
My blog: http://www.RyanVice.net/- Marked As Answer byGuillermo Martelli Wednesday, November 04, 2009 1:11 PM
- Ryan:
Thanks for the info. I was hoping some of you with more experience would chime in.
I agree that error handling is a pain. I can also add that the documentation is quite lacking on that aspect (and several others). It doesn´t help that they are already discontinuing everything for WF4. Sad.
I´ll handle it the same way I treat WorkflowAborted then, by suspending and waiting for manual operator intervention (to fix the problem and resume it). That should continue from the last persistence point (our workflows tend to be most of the time waiting for input, so they are mostly in persistence). Thanks a lot. - Well good luck with that
I created this article on my blog about implementing an AbortingSQLPersistenceService which we use in my system. It's not for service layer exceptions but it was something that was useful in our system for getting the 4.0 "abort on unhandled exception" functionality.
http://www.ryanvice.net/uncategorized/abort-on-error-in-windows-workflow-foundation-3-5/
If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
My blog: http://www.RyanVice.net/


