Тщательно использовать операторы if или блоки try / catch?

Question

Дайте мне несколько мыслей о том, что является лучшей практикой кодирования / делает более эффективный код / ​​выглядит красивее / безотносительно: Увеличение и улучшение вашей способности использовать операторы if для прогнозирования и выявления потенциальных проблем? Или просто хорошо использовать try / catch в целом?

Допустим, это для Java (если это имеет значение).

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

Answer 1

эта дискуссия (2003) была хорошей:

http://www.joelonsoftware.com/items/2003/10/13.html

http://nedbatchelder.com/blog/200310/joel_on_exceptions.html

Answer 2

if блоки немного быстрее; если вам не понадобится дюжина из них, это лучшая идея, чем try/catches. Исключения должны быть исключительными, не каждый раз, когда код выполняется. Я использую исключения для редких событий, таких как отключение сервера (даже если они происходят несколько раз в день) и if блоков для любых моих контролируемых переменных.

Answer 3

Независимо от того, какой код вы пишете, вы в конечном итоге будете использовать оба. Я не могу говорить о среде выполнения Java, но в среде выполнения .NET наблюдается снижение производительности, связанное с использованием блоков try-catch. В результате я стараюсь использовать их только в тех областях, где у меня есть четкий способ обработать исключение, которое однажды было обнаружено (даже если оно просто регистрирует наличие проблемы).

Если вы обнаружите, что используете в своем коде множество блоков try-catch или блоков if-else или ваши методы имеют тенденцию быть довольно длинными, рассмотрите возможность рефакторинга кода в большее количество меньших методов. Намерение вашей логики будет легче следовать, а также проще для модульного тестирования.

Answer 4

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

И исключения замедляют ход событий.

Answer 5

Из того, что мне сказали более опытные разработчики и аналитики, try / catch является более объектно-ориентированным, а если и более процедурным.

Мне лично все равно.

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

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

Иногда я явно заключаю некоторые операторы if в try / catch, но в любом случае.

Я использую if, если для проверки (1 или 2) перед выполнением того, что мне нужно, требуется лишь небольшое количество вещей.

Answer 6

My 2p: лучше использовать try / catch:

• другим кодировщикам совершенно ясно, что вы выполняете обработку исключений
• компилятор понимает, что вы делаете, и может выполнить для вас более подходящие проверки во время компиляции

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

Answer 7

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

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

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

Answer 8

@ PersonalPerson - Извините, но это просто ленивое кодирование. Вместо использования try-catch, потому что там слишком много операторов if, почему бы не реорганизовать ваш код (т.е. поместить вашу логику проверки в свой собственный метод). Это сделает ваш код чище и более читабельным, а также поддержит лучшие практики для повышения производительности.

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

Клянусь, я уже работал с твоим кодом, и у меня болит голова.

Answer 9

Есть одна вещь, которая здесь не упоминалась.

С оператором if-else при каждом запуске кода гарантируется выполнение как минимум 1 из условия. Я уверен, что мы все знаем, как работает if-else-elseif, но для ясности ... часть if оператора всегда будет оцениваться, если оно ложно, то следующее else -if оценивается и так далее до тех пор, пока для оценки не останется только else .

Таким образом, использование оператора if-else повлияет на вашу производительность. Незначительно (в большинстве случаев), но для оценки требуется процессорное время.

операторы try-catch и исправьте меня, если я ошибаюсь, не учитывайте во время выполнения, пока они не потребуются (т.е. выдается исключение). Поэтому простое завершение кода в try-catch не повлияет на производительность до тех пор, пока оно фактически не будет обнаружено.

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

И одно из важных замечаний: операторы try-catch НИКОГДА не должны использоваться для условной логики. Они должны использоваться только для того, для чего они предназначены: обработка исключений!

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

Обычно хорошей идеей будет иметь обработчик исключений на абсолютном верхнем уровне вашего приложения, чтобы отлавливать исключения до того, как их увидит пользователь. В ASP.NET вы можете сделать это в событии Application_Error файла global.asax. В других языках / средах вы делаете это в основном цикле, что бы это ни было.

Но обратите внимание, есть некоторые исключения, которые всегда лучше всего оставить незатронутыми. Иногда, когда возникает исключение, это показатель того, что состояние вашего приложения было серьезно скомпрометировано и ему нельзя доверять. Единственная безопасная вещь - убить и перезапустить.