Использование необработанных исключений вместо Contains ()?
вроде разобрался в этом сам. я пытался использовать формат JSON без правильного анализа выходной строки в JSON. Добавлена функция анализа JSON () на сервере:
Response.ContentType = "application/json"
Response.Write "{ ""data"": " & toJSON(dropdownHtml) & ", ""total"": " & userCount & " }"
8 ответов
Я должен был бы сказать, что это - довольно плохая практика. Пока некоторые люди могли бы быть рады сказать, что цикличное выполнение через набор менее эффективно к выдаче исключения, существуют издержки к выдаче исключения. Я также подверг бы сомнению, почему Вы используете набор для доступа к объекту ключом, когда Вы лучше подошли бы для использования словаря или хеш-таблицы.
Моя основная проблема с этим кодом однако, то, что независимо от типа выданного исключения, Вы всегда собираетесь быть покинутыми с тем же результатом.
Например, исключение могло быть выдано, потому что объект не существует в наборе, или потому что сам набор является пустым или потому что Вы не можете бросить myCollect[myObject] к aObject.
Все эти исключения будут обработаны таким же образом, который не может быть Вашим намерением.
Это несколько хороших статей о том, когда и где usally считают приемлемым выдать исключения:
Мне особенно нравится эта кавычка от второй статьи:
Важно, чтобы исключения были выданы только, когда неожиданное или недопустимое действие происходит, который препятствует тому, чтобы метод завершил свою нормальную функцию. Обработка исключений представляет маленькие издержки и понижается, производительность так не должна использоваться для нормального процесса выполнения программы вместо условной обработки. Может также быть трудно поддержать код, который неправильно использует обработку исключений таким образом.
Если при написании кода Вы ожидаете этот объект быть в наборе, и затем во время времени выполнения Вы находите, что это не, я назвал бы это исключительным случаем, и следует использовать исключение.
Однако, если Вы просто тестируете на существование объекта, и Вы находите, что это не там, это не исключительно. Используя исключение в этом случае не является надлежащим.
Анализ производительности во время выполнения зависит от фактического набора, используемого, и метод при поиске его. Это не должно иметь значения все же. Не позволяйте иллюзии оптимизации одурачить Вас в написание запутывающего кода.
Общее эмпирическое правило состоит в том, чтобы избегать использования исключений для потока управления, если обстоятельства, которые инициируют исключение, не будут "исключительными" - например, чрезвычайно редкими!
Если это - что-то, что будет происходить обычно, и регулярно это определенно не должно быть обработано как исключение.
Исключения очень, очень медленные из-за всех включенных издержек, таким образом, могут быть причины производительности также, если это происходит достаточно часто.
Смотрите на это сообщение в блоге от Krzystof: http://blogs.msdn.com/kcwalina/archive/2008/07/17/ExceptionalError.aspx
Исключения должны использоваться для передачи состояний ошибки, но они не должны использоваться в качестве управляющей логики (особенно, когда существуют намного более простые способы определить условие, то, которое Содержит).
Часть проблемы - то, что исключения, в то время как не дорогой для броска являются дорогими для ловли и все исключения, пойманы в какой-то момент.
В целом использование обработки исключений для процесса выполнения программы и логики является плохой практикой. Я лично чувствую, что последняя опция является недопустимым использованием исключений. Учитывая функции языков, наиболее часто используемых в эти дни (такие как Linq и лямбды в C#, например) нет никакой причины не записать, что Ваше собственное Содержит () метод.
Наконец, в эти дни большинство наборов действительно имеет уже, содержит метод. Таким образом, я думаю по большей части, что это - надуманный вопрос.
Я должен был бы думать об этом больше относительно того, насколько мне нравится он... мой инстинкт пищеварительного тракта, а, не так...
Править: Комментарии Ryan Fox к исключительному случаю прекрасны, я соглашаюсь
Что касается производительности, это зависит от индексатора на наборе. C# позволяет Вам переопределить оператор индексатора, поэтому если бы он делает для цикла как, содержит метод, который Вы записали бы, затем это будет так же, как медленное (с, возможно, несколькими наносекундами медленнее из-за попытки/выгоды..., но ничто для волнения о том, если тот код сам не в огромном цикле).
Если индексатор является O (1) (или даже O (журнал (n))... или что-либо быстрее, чем O (n)), то решение для попытки/выгоды было бы быстрее, конечно.
Кроме того, я предполагаю, что индексатор выдает исключение, если это возвращает пустой указатель, Вы могли бы, конечно, просто проверить на пустой указатель и не использовать попытку/выгоду.
Исключения должны быть исключительными.
Что-то как 'Набор отсутствует, потому что база данных выпала из-под него', является исключительным
Что-то как 'ключ не присутствует', нормальное поведение для словаря.
Для Вашего определенного примера набора Управления winforms, Controls свойство имеет a ContainsKey метод, который является тем, что Вы, как предполагается, используете.
Существует нет ContainsValue потому что при контакте со словарями/хеш-таблицами, нет никакого быстрого пути за исключением итерации через весь набор проверки, если что-то присутствует, таким образом, Вы действительно отговорены делать это.
Что касается того, ПОЧЕМУ Исключения должны быть исключительными, это - приблизительно 2 вещи
Указание, что код пытается сделать. Вы хотите иметь свое соответствие кода, чего это пытается достигнуть, максимально тесно, таким образом, это читаемо и удобно в сопровождении. Обработка исключений добавляет набор дополнительного хлама, который мешает этой цели
Краткость кода. Вы хотите, чтобы Ваш код сделал то, что он делает самым прямым способом, таким образом, это читаемо и удобно в сопровождении. Снова, хлам, добавленный обработкой исключений, мешает этому.
Последний является приемлемым решением. Хотя я определенно уловил бы смысл определенное исключение (ElementNotFound?), который набор бросает в этом случае.
Speedwise, это зависит от общего падежа. Если Вы, более вероятно, найдете элемент, чем не, решение для исключения будет быстрее. Если бы Вы, более вероятно, перестанете работать, то это зависело бы от размера набора и его итеративной скорости. Так или иначе Вы хотели бы иметь размеры против нормальной эксплуатации, чтобы видеть, на самом деле ли это - горлышко бутылки прежде, чем вызвать беспокойство о скорости как это. Пойдите для ясности сначала, и последнее решение намного более ясно, чем первый.