Что факторы должны быть учтены при записи пользовательского класса исключений?

Я согласен с TKK

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

Первый оператор switch будет устанавливать sqlcommand и параметры, а второй останется неизменным в цикле while.

Объявите их в начале вашего метода:

`SqlConnection conn = new SqlConnection("connection string");
 SqlCommand cmd = AdoBase.GetSqlCommand("", conn);`

Измените первый оператор switch, чтобы добавить параметры в команду sql:

switch (model.Attribute)
{
    case "Users":
        sqlCommand = "GeneralUserSearch";
        if (!string.IsNullOrWhiteSpace(model.Name))
        {
            cmd.Parameters.AddWithValue("Name", model.Name);
        }

        if (!string.IsNullOrWhiteSpace(model.Name))
        {
            cmd.Parameters.AddWithValue("Username", model.Username);
        }

        break;
    case "Favorites":
        sqlCommand = "UserFavorites";
        cmd.Parameters.AddWithValue("Favorites", model.Favorites);
        break;
    case "Email":
        sqlCommand = "EmailSearch";
        cmd.Parameters.AddWithValue("Email", model.Email);
        break;
}

Удалите этот блок кода:

switch (model.Attribute)
{
    case "Users":
        if(!string.IsNullOrWhiteSpace(model.Name)) {
            cmd.Parameters.AddWithValue("Name", model.Name);
        }
        if(!string.IsNullOrWhiteSpace(model.Name)) {
            cmd.Parameters.AddWithValue("Username", model.Username);
        }                                                           
        break;
    case "Favorites":
        cmd.Parameters.AddWithValue("Favorites", model.Favorites);
        break;
    case "Email":
        cmd.Parameters.AddWithValue("Email", model.Email);
        break;                                             
}

И добавьте, наконец, после улова, чтобы очистить объекты соединения и команды:

 finally
 {
    conn.Dispose();
    cmd.Dispose();
 }
6
задан Community 23 May 2017 в 12:01
поделиться

7 ответов

Вопросы спросить себя:

  1. Кто будет ловить его? Если никто, то Вам действительно не нужно пользовательское исключение.
  2. Где Вы будете бросать его? Действительно ли там достаточно контекста легко доступно, или необходимо ли будет поймать и несколько раз повторно бросать ли, прежде чем исключение полезно для заключительного ловца?
  3. Почему Вы бросаете его? Поскольку Вы поймали исключение и потребность присоединить дополнительную информацию? Поскольку Вы встретились с неисправимой ошибкой в некоторых данных и потребностью передать специфические особенности назад к клиентскому коду? Поскольку Вам нравится throwвещи луга?
  4. Каково исключение? Не, что вызвало его, а что это с точки зрения ловца? Что-то они могут зафиксировать и повторить? Что-то они никогда не должны повторять? Что-то они должны уведомить пользователя о? Что-то они должны присоединить контекстную информацию к и затем повторно бросить? Что определяет информацию, необходимо будет провести, если любой...

Предписания:

  1. Не напрасно тратьте время на пользовательских исключениях, которые никогда не будут пойманы.
  2. Не "сгибайте" исключения: каждый пользовательский тип исключительной ситуации должен иметь четко определенный случай, где он может и должен быть пойман; исключения, которые не соответствуют, должны вспыхнуться в их собственные типы (вместо того, чтобы, скажем, вынудить ловца встроить условную логику в сингл catch() пункт).
  3. Если Вы не имеете серьезное основание не к, всегда позволяете присоединять внутреннее исключение / данные из ранее-перехваченной-исключительной-ситуации. Потеря контекста редко полезна.
10
ответ дан 8 December 2019 в 16:13
поделиться

Я - немного минималист и только создам пользовательское исключение, если существует код вызова, который должен явно реагировать на конкретное условие, которое произошло. Для всех других ситуаций я буду использовать самое соответствующее исключение библиотеки.NET. Например, ArgumentNullException, InvalidOperationException

1
ответ дан 8 December 2019 в 16:13
поделиться

Когда необходимо отличить одно исключение от других так или иначе. Вот именно, действительно. Конечно, Вы могли создать класс исключений, который берет перечисление для различения его причины, также.

Это действительно легко видеть, когда Вы хотите передать дополнительную информацию за исключением. Единственная причина передать ту информацию состоит в том, если Вы хотите смочь получить ту информацию позже, и таким образом, Вы захотите знать тип, таким образом, можно будет получить информацию от того типа и не других.

В C++ и возможно некоторых других языках, Вы могли бы также определение типа исключение. Это позволило бы, чтобы тип различал, и возможно будущее преобразование в пользовательский класс.

1
ответ дан 8 December 2019 в 16:13
поделиться

Как сказанная Езда на заднем колесе мотоцикла, сначала ищите соответствующее исключение платформы и только используйте исключения (особенно пользовательские исключения), где Вы действительно планируете поймать их.

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

Если Вы используете.NET, выезд, Разрабатывая Пользовательские Исключения. Интересно, документация изменила свою рекомендацию на использовании ApplicationException:

При разработке приложения, которое должно создать его собственные исключения, Рекомендуется получить пользовательские исключения из Класса исключений. Первоначально считалось, что пользовательские исключения должны произойти из класса ApplicationException; однако на практике это, как находили, не добавило значительное значение. Для получения дополнительной информации посмотрите Лучшие практики для того, чтобы Обработать Исключения.

1
ответ дан 8 December 2019 в 16:13
поделиться

Моей главной причиной для использования пользовательских исключений была бы инкапсуляция с несколькими поставщиками: наличие утечки SqlException из уровня SqlDataAccess и SocketException из уровня NetworkDataAccess делает код вызова зависящим от подробных сведений Вашей реализации. Лучше переносить их в DataAccessException или что-то.

1
ответ дан 8 December 2019 в 16:13
поделиться

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

1
ответ дан 8 December 2019 в 16:13
поделиться

Я думаю, что простой ответ, "Создают пользовательское исключение, когда никакое существующее исключение adequetely не выражает исключительной ситуации".

У меня также есть второе правило, что я подаю заявку: "Только создайте пользовательское исключение, если Вы ожидаете, что разработчик сможет обработать исключение". Нет никакого смысла в создании нового исключения, если Вы не считаете исключение восстанавливаемым условием. Это - больше effectient для броска InvalidOperationException в тот контекст.

Править: Законченная запись сообщения в блоге на этом предмете: http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

0
ответ дан 8 December 2019 в 16:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: