Best practices for handling a web service failure?

Silently retry once or twice, and then fail with a warning to the user.

Silently retry once or twice, and then fail with a warning to the user. To avoid duplication include a unique id with each individual request, and on the server discard requests with identical ids.

There is a pitfall with automatic retries, in that if each tier retries a few times, it can soon escalate; See also: blogs.msdn. Com/oldnewthing/archive/2005/11/07/489807. Aspx – Rowland Shaw Mar 16 '09 at 21:43 Very valid point, and something to watch out for.

When doing something similar I was sure to test the app in a range of ways. A single automatic retry was enough for me, before warning the user on the second failure. Errors do tend to "just happen", out in the wild, which do need some handling.

– MattJ Mar 16 '09 at 21:50 Silent retries can also be missed during support problems. It makes the code a little harder to debug (unless you add in a mode to warn each time). I wasted a lot of time with IE once because of this.

– Paul W Homer Mar 16 '09 at 21:55.

As you say, there's no right or wrong answer, the choice has to be made depending on specific circumstances : A webmail polling for new messages will fail silently, retry and warn the user if the server is ureachable after a certain amount of retries (like a mail client would do) A page loading its content dynamically will immediatly let the user know that the content is unavailable, and why not let him trigger the retry (like any browser would do) etc There's no right answer, but I think it would be a shame to be able to intercept a web service failure and then automate this bad habit users (we) have : retry, retry, retry...

Lately I've been using Google Docs from home. On occasion, my connection goes down for a while and then eventually returns. I like to know when the app has trouble saving (which is does at various intervals), but I'm not always necessarily concerned when it does, and I don't want a model interruption (just a message somewhere).

If it's really bad (can't save for a long time), I'll just copy the whole buffer out to a notepad and save it as a backup. That's a great example because my 'transaction' is essentially local until I need to save it. The context is on my PC for a while, then the server, then my PC again.

If the app hung each time it couldn't work, I'd not be able to use it for anything non-trivial. If the app is just a screen that accesses a server, then the local portion of it is trivial. It should keep the user informed about the current state of the 'transaction' (success or failure).

So it really depends on how much of the context is local and how much is remote ... Paul.

It depends on your use case. Is failure something you can recover from? What is the expected frequency of the failure?

The level of effort to "retry" the operation may outweigh the benefits. Use your knowledge of your application to determine if implementing complicated error handling is worth it... Often it is not.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.