Какую обработку исключений я должен выбрать для подключения клиента - PullRequest
3 голосов
/ 19 января 2011

У меня есть клиентский класс, который подключается к серверу через WebRequest.Сейчас я борюсь с тем, как лучше всего реализовать обработку WebException.Для получения хорошего отзыва о пользовательском интерфейсе мне нужно (пока) сообщение об исключении и статус.

Я предложил три разных подхода.Первый просто перебрасывает исключение, и я выполняю обработку в вызывающем методе.Это может быть наиболее универсальным решением:

public class ClientSimpleRethrow
{
    public bool IsConnected { get; set; }

    public void Connect()
    {
        try
        {
            // do connection
        }
        catch (WebException)
        {
            IsConnected = false;
            throw;
        }

        IsConnected = true;
    }
}

Вторая версия выдает пользовательское исключение с WebException в качестве внутреннего исключения.Это дает мне преимущество только ловить и обрабатывать именно то, что я ожидаю.Например, может быть другая ошибка, которая также выдает WebException, которую я хотел бы обработать по-другому.Пока что это мое любимое решение:

public class ClientThrowCustom
{
    public bool IsConnected { get; set; }

    public void Connect()
    {
        try
        {
            // do connection
        }
        catch (WebException ex)
        {
            IsConnected = false;
            throw new ClientConnectionException(ex.Message, ex);
        }

        IsConnected = true;
    }
}

Я бы мог подумать и о третьей возможности.Исключение перехватывается, и я устанавливаю только те свойства, которые мне действительно нужны для обработки исключения в пользовательском интерфейсе.Информация о том, что что-то пошло не так, у меня уже есть в свойстве IsConnected.Преимущество этого решения состоит в том, что вы не поймаете дважды.

public class ClientProperties
{
    public bool IsConnected { get; set; }
    public string ConnectionErrorMessage { get; set; }
    public WebExceptionStatus? ConnectionErrorStatus { get; set; }

    public void Connect()
    {
        try
        {
            // do connection
        }
        catch (WebException ex)
        {
            IsConnected = false;
            ConnectionErrorMessage = ex.Message;
            ConnectionErrorStatus = ex.Status;
            return;
        }

        IsConnected = true;
        ConnectionErrorMessage = null;
        ConnectionErrorStatus = null;
    }
}

Мне понадобится совет по передовой практике, какой из них выбрать и почему.Я надеюсь, что этот вопрос не слишком субъективен, потому что я действительно думаю, что должны быть некоторые веские факты, чтобы выбрать один дизайн из других.

Заранее спасибо за вашу помощь!

1 Ответ

2 голосов
/ 19 января 2011

Для начала, я думаю, что третий метод плох. Преимущества исключений в том, что они не заставляют вызывающий контекст проверять коды ошибок перед продолжением. Внутри блока try вы можете написать свой код, как если бы каждая функция была успешной. Третий метод убирает эту тонкость и делает вызывающий код более сложным.

Что касается первых двух, я предпочитаю второе. В моих глазах есть два преимущества:

  • Вы можете создать класс Exception, который что-то означает в контексте вашего приложения, а не обходить контекст базового API. WebException подходит для API, но если вы получаете его методом, когда пытаетесь войти в какую-либо систему, LogInException более полезен на верхних уровнях вашего приложения.

  • Пользовательские исключения позволяют начинать с базового MyApplicationException класса и строить его оттуда. Оттуда вы можете поймать исключения API и превратить их в MyApplicationException дочерние исключения как можно скорее. Таким образом, когда исключение API появляется в вашем приложении, вы сразу же знаете, что есть какой-то угловой случай, который вы не учли и нуждаетесь в решении. Если исключение для необработанного приложения означает, что вы неправильно используете свой собственный код.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...