Catching exceptions & keeping GUI logic seperate

Question

How would you correct way to handle an exception in this situation? Initially I expect that using a trycatch in the following manner would catch the exception thrown by the helper class when the upload fails.

My aim is for "false" to be returned and a Messagebox to open with the error message I'll be plucking out of the HTML response from my upload attempt. I am trying to do this without resorting to bad practise and putting GUI code inside my helper class.

        try
        {
            // returns bool
            successful = UploadHelper.Upload(uploadToPath, File.ReadAllBytes(uploadFromPath), properties);
        }
        catch (Exception ex)
        {
            string error = ex.Message;
        }

Helper class:

    public static bool Upload(string webUrl, string documentName, byte[] bytes, Dictionary<string, object> metaInfo, out string result)
    {
        try
        {
            using (WebClient webClient = new WebClient())
            {
                //result is HTML string containing data
                result = Encoding.UTF8.GetString(webClient.UploadData(webUrl + "/_vti_bin/_vti_aut/author.dll", "POST", data.ToArray()));

                // if fails throw exception
                if (result.IndexOf("\n<p>message=successfully") < 0)
                    throw new Exception(result);
            }
        }
        catch (Exception ex)
        {
            result = ex.Message;

            // Upload failed
            return false;
        }
        // Upload succeeded
        return true;
    }

This slightly similar question lead me to thinking I could resolve this issue with a custom exception. However reading this explanation of creating them has confused me as to how they could be used to resolve this situation - as it seems this would just move the Messagebox code to the Exception class which is also not a great place for it.

I am fairly sure this is a situation where I am justified in using a custom exception anyway as the user may be able to resolve the issues depending on the error message returned. So I have written from the aforementioned guide anyway (left out of code example for simplicity).

David M · Accepted Answer · 2012-07-04T14:46:31.333

5

If you are just going to display the exception's message in the UI, and your catch block here is just to grab the message, why catch it here at all? If the handling is in the UI, then catch it there (or closer to there) and just grab and display the message at that level.

You'd generally use exception handling in this sort of case to either grab specific exceptions and extract information from them to report in a particular way (abstract the error message as Charleh comments below), or to drive some sort of automatic retry logic. But there's absolutely nothing wrong with a method called Upload throwing an exception if it fails to upload something.

edited Jul 04 '12 at 14:46

answered Jul 04 '12 at 14:27

David M

71,481
13
158
186

Agreed - if you are handling a potential error in your GUI just put the exception handling there - it doesn't look like you want to abstract the error message so let the method throw and catch it at UI level – Charleh Jul 04 '12 at 14:30
I understand you, I may have been over thinking things. The issue I still see is the HTML string could return other errors, it could be from a miss-typed field (giving not found) or a server error could be causing the fault... would this be "abstracting the error message" in the way you mean. – Amicable Jul 04 '12 at 14:48
1

Sort of. If you want THIS METHOD to behave differently depending on the exception encountered, then handle it here. If you want to do the same thing here regardless of the exception (e.g. just pass back the message) then this is the wrong place to handle it. – David M Jul 04 '12 at 15:13

Catching exceptions & keeping GUI logic seperate

1 Answers1