C# Returning something from exception handle

Question

Hello,

I have the following code in a class of mine. The purpose of this class is to get the balance from a web server. Just in case something goes wrong with getting the balance. I will handle a exception. However, all this is easy to do. But I am left wondering what do I return in my catch statement.

Most of the examples I looked at just write to the console using:

Console.WriteLine(ex.Message);

That is all very well. But in a real application what do most developers do?

 //Download only when the webclient is not busy.
        if (!wc.IsBusy)
        { 
            // Sleep for 1/2 second to give the server time to update the balance.
            System.Threading.Thread.Sleep(500);

            try
            {
                // Download the current balance.
                wc.DownloadStringAsync(new Uri(strURL));
            }
            catch (WebException ex)
            {
                Console.Write("GetBalance(): " + ex.Message);
            }
        }
        else
        {
            Console.Write("Busy please try again");
        }

My function at the moment returns void. And I am just wondering what else I would return if the webclient is busy?

Many thanks for any advice,

Answer 1

You could re-run the method if the client is busy but wait a certain time before retries? Potentially with a failure after x retries.

If instead you wish to move on and simply log the problem, your catch statement could log the exception to a file-based log, event viewer, submit to a database, raise an alert (email, sms etc.) if it is necessary.

Answer 2

You should use ex.ToString() method

Exception.Message contains a simple description of the exception (e.g. "Object reference not set...").

Exception.ToString() contains a description of the exception along with a complete stack trace.

Exception Handling Best Practices in .NET

Answer 3

Do not catch an exception if you cannot handle it. If you return just some value, the calling method has to check if the value is a real result or just an indicator of an exception. And now this method must decide what to do and return. And the method calling this method. And the method...

So just let the exception bubble up the stack and catch it somewhere where you can handle it. Maybe directly below the user interface and then display a message box asking if the user wants to retry or display information how to solve the problem. If you have no user interface, catch it somewhere where you can solve the problem and retry. If it is a temporary problem, retry the whole task at a reasonable level until the call succeeds.

If you want to log something, use the following pattern to log the exception an rethrow it.

try
{
   DoStuff();
}
catch (Exception exception)
{
   Log(exception.ToString());

   throw;
}

Note that it is throw; and not throw exception;. If you do the later, you lose the original stack trace. If you can infer more details about the cause of the exception, you should wrap the caught exception into a more meaningful exception with additional information.

try
{
   DoStuff();
}
catch (SpecificMeaninglessException exception)
{
   Log(exception.ToString());

   throw new MeaningfulException("Details about the error.", exception);
}
catch (Exception exception)
{
   Log(exception.ToString());

   throw;
}

Answer 4

Depends on the severity of the exception.

I would suggest looking into The Exception Block from Patterns & Practices

Answer 5

If you're only interested in viewing the exception you should re throw the exception so who-ever is planning on handling it will still get it.

Answer 6

You certainly don't want to mask an unhandled exception. Let that bubble up through the stack. But if you are asking what to return if the web client is just busy, how about returning either a random interval or some meaningful interval that the function caller should wait before attempting to download the balance again? A random number could distribute load or otherwise mitigate a collision problem. A more meaningful interval could be sent back based on the the current state of the server.