У меня есть запрос на вставку, который возвращает интервал. На основе того интервала я могу хотеть выдать исключение. Действительно ли это является соответствующим, чтобы сделать в операторе переключения?
switch (result)
{
case D_USER_NOT_FOUND:
throw new ClientException(string.Format("D User Name: {0} , was not found.", dTbx.Text));
case C_USER_NOT_FOUND:
throw new ClientException(string.Format("C User Name: {0} , was not found.", cTbx.Text));
case D_USER_ALREADY_MAPPED:
throw new ClientException(string.Format("D User Name: {0} , is already mapped.", dTbx.Text));
case C_USER_ALREADY_MAPPED:
throw new ClientException(string.Format("C User Name: {0} , is already mapped.", cTbx.Text));
default:
break;
}
Я обычно добавляю операторы завершения к переключателям, но они не будут поражены. Действительно ли это - плохой дизайн? Совместно используйте любые мнения/предложения со мной.
Спасибо, ~ck в Сан-Диего
Почему бы и нет?
Из Язык программирования C #, Третье изд. Андерса Хейлсберга и др., Стр. 362:
Список операторов раздела switch обычно заканчивается
break
,goto case
илиgoto default
, но разрешена любая конструкция, которая делает конечную точку списка операторов недостижимой. [...] Аналогично, операторthrow
илиreturn
всегда передает управление в другое место и никогда не достигает своей конечной точки. Таким образом, следующий пример действителен:switch (i) { case 0: while (true) F (); case 1: throw new ArgumentException (); случай 2: return; }
Я не совсем согласен с вашими соглашениями об именах переменных;), но я не согласен понять, почему то, что вы сделали, было бы неуместным. Это кажется довольно элегантным способом перевода ошибки с одного носителя на другой.
Я предполагаю, что ваш «запрос на вставку» - это некая форма хранимой процедуры.
Если возможно, было бы лучше, если бы вы бросали туда, где установлен неудачный результат, иначе вам придется выполнять как проверку результата, так и бросание. Но, конечно, это может быть невозможно.
Кроме того, я бы превратил ваши строки ошибок в ресурсы или константы с заполнителями, чтобы вам не приходилось менять несколько мест, если вы хотите изменить формулировку.
Я не вижу проблем с использованием переключателя в вашем случае.
Более пристальное внимание следует уделить тому, уместны ли сами исключения. Как правило, исключения следует использовать только тогда, когда возникает ситуация, выходящая за рамки ожидаемого поведения. Исключения не следует использовать в качестве логики выполнения программы. В вашем случае вы, вероятно, можете использовать их на основе кода, который я вижу.
Думаю, это нормально. Похоже, вы сопоставляете код возврата с исключением, используя оператор switch. Пока случаев не так много, это не проблема.
Нет проблем ... почему это будет плохой дизайн?
В качестве альтернативы, поскольку тип исключения один и тот же во всех случаях
s, вы можете создать таблицу поиска для сообщений об ошибках. Это избавит вас от дублирования кода. Например:
static private Dictionary<int, string> errorMessages;
static
{
// create and fill the Dictionary
}
// meanwhile, elsewhere in the code...
if (result is not ok) {
throw new ClientException(string.Format(errorMessages[result], cTbx.Text, dTbx.Text));
}
В самих сообщениях вы можете выбрать соответствующий параметр с помощью {0}
, {1}
и т. Д.
Возможно, я позволю себе отличаться от всех ответов здесь ..
Вместо того, чтобы переключать код, я бы предпочел передать result
в класс ClientException
и пусть он сам решает, какую строку ему нужно отображать, вместо того, чтобы иметь уродливый переключатель повсюду для создания различных сообщений
Мой код будет выглядеть так:
throw new ClientException(result, cTbx.Text);
Так что, даже если вы можете выдавать ошибки в switch ... case
, вы можете избежать всего этого, это мое мнение
В выбранном вами подходе нет ничего плохого. Операторы переключения намного легче читать, чем операторы if / then (и потенциально быстрее). Еще вы можете загрузить возможные исключения в
Dictionary<Result_Type, Exception>
и вытащить оттуда исключение. Если у вас много операторов switch, это сделает код более компактным (и вы можете добавлять и удалять их во время выполнения, если вам нужно).