Web Service Reconnecting pattern

I'm developing a .Net Webform application, with heavy use of web services to communicate with an outside-server database.

So, I'm trying to find the best way to deal with disconnections and failures when calling a WS method.

For now, I've made a proxy function -kind of a layer- for every WS method I call, that repeats the specific WS call in a loop until it cames out successfully.

For Both Sync and Async calls, I've solved my problem, but I added an annoying extra layer to my WebService layer, with extra maintenance, and a lot of redu开发者_JS百科ndant code.

I refuse to believe there's not an existing solution for this standard situation, but can't find it anywhere.

Any Ideas?

Following, an example of my extra layer (Sync):

public static int WsMethod(string param1, int param2)
{
 while(true)
 {
  try
  {
   return new Webpoint().WsMethod(param1, param2);
  }
  catch (Exception)
  {
   Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
  }
 }
}

And Async:

    public static void WsMethodAsync(string param1, int param2, WsMethodCompletedEventHandler handler)
    {
        while (true)
        {
            try
            {
                var server = new Webpoint();
                server.WsMethodAsyncCompleted += delegate(object sender, WsMethodAsyncCompletedEventArgs args)
                {
                    if (args.Error != null)
                    {
                        Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
                        this.WsMethodAsync(param1, param2, handler);
                    }
                    else
                    {
                        handler(sender, args);
                    }
                };
                server.WsMethodAsyncAsync(param1, param2);
                return;
            }
            catch (Exception)
            {
                Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
            }
        }
    }

I would not recommend this pattern. If there is some problem with the parameters on your call this will run forever. Normaly I would catch the few expected exceptions (CommunicationException, SocketException, whatever you need) and return some status-code for this (Ok, or NoNetwork, or whatever). Or wrap up all expected exceptions into a MyCommunicationException and throw this (to hide implementation details from the caller and make exception-handling easier for it)

But give the control back to the caller and let the caller decide how to go on. Don't catch the other unexpected exceptions or rethrow them.

The caller can then decide to try time and again or 3-times or whatever.

If something were genuinely wrong with the service, or the connection thereto, or the request being made, then this would repeat indefinitely without ever telling you what's wrong.

What are the implications of the service call failing? How often does it really fail? And, most importantly, for what reason does it fail? If the reason is something that can be fixed, it should be fixed. Not worked around.

As a simple example, if this back-end service call is something initiated by a user of the website (say, they're trying to fetch some data to edit) then if the call fails you just present an error to the user. Something like:

"I'm sorry, but that data is not available at this time. The support team has been notified of this problem. Please try your request again. If the problem persists, contact the help desk at 800-555-1234."

Now, this shouldn't just be a single generic error to show the user no matter what happens. The code needs to be robust enough to discern one kind of error from another. If the service is unreachable, this error applies. If the service is saying that the request is invalid, then there's something wrong either with that the user is doing or what your code is doing, and that needs to be fixed. Etc.

How you deal with the errors and maintain a usable application is ultimately up to you and the business overall. But I honestly can't recommend the approach you outline on the question. That approach doesn't solve anything, it just ignores the problem until it gets worse. You need to determine the root cause of the errors and address that, not ignore them.

Also, any time an error is suppressed/ignored, a kitten dies.