Лучше использовать попытку/выгоду вместо нескольких операторов IF?
Это лучше, менее дорого или более читаемо для использования a try/catch блок в Java вместо того, чтобы использовать несколько If операторы для проверки ввода данных пользователем, например?
Пример при парсинге a Date представьте в виде строки, не будет это быть лучше проанализировать непосредственно использование блока попытки/выгоды вместо того, чтобы писать несколько операторов, ища запрещенные символы.
В другом примере скажите, что я хочу считать файл или поток вместо использования Scanner, Я просто вызываю метод и ожидаю исключения для появления.
Это - здоровый метод программирования? Действительно ли это менее дорого на Виртуальной машине?
ОБНОВЛЕНИЕ
Вот пример того, что я имел в виду при использовании исключения DateFormat, иногда это могла быть настоящая проблема зафиксировать ошибку, и при выполнении так, можно ли гарантировать сложное (обычно нечитабельный), код подвержен ошибкам?
7 ответов
Использовать исключения для потока - плохая практика. контроль.
Некоторые цитаты:
Поскольку исключения предназначены для использования в исключительных обстоятельствах, немногие, если они вообще есть, реализации JVM пытаются оптимизировать свою производительность. Как правило, создавать, генерировать и перехватывать исключение дорого.
При наличии несвязанной ошибки идиома может молча дать сбой и замаскировать ошибку, значительно усложняя процесс отладки .
Обновление: Как сказано (и я помню, что я также нашел то же утверждение в блоге Джоша Блоха), использование исключений для управления потоком похоже на использование GOTO для той же цели. Вы можете прочитать интересную статью Дейкстры о том, почему GOTO плохие.
Исключения составляют исключительные случаи. Делать программную логику зависимой от генерируемых исключений - плохая идея.
В общем, исключения предназначены для ... ну, исключительных событий. Если предназначен для вещей, которые могут произойти при обычном ходе событий.
Обычно, если вы хотите разобраться с делом, для которого у вас нет хорошего локального решения, используйте исключение, чтобы распространить его наверх тому, кто может с ним справиться лучше. Это значительно дороже, чем if-else , и это еще одна причина не злоупотреблять им. Третья, IMHO не менее важная проблема - удобочитаемость: гораздо труднее проследить, где поток выполнения продолжается после throw , чем читать последовательность if операторов.
Если вы хотите обрабатывать дело локально, в большинстве случаев лучше использовать простой if .
Я думаю, было бы дороже, если бы попытка catch перехватила исключение, плюс операторы if, вероятно, выглядели бы чище.
Дороже использовать Exception вместо If, потому что компилятору и jvm будет сложнее и труднее оптимизировать поток управления этих блоков, да и вообще исключения предназначены для исключений.
Исключения не хороши для производительности, поскольку они предназначены для исключительных обстоятельств, и, таким образом, существуют компромиссы, которые делают неисчернительный случай быстрее за счет замедления исключений. При этом невозможно сказать, является ли разница значительной в конкретном случае без бенчмаркинга этого конкретного случая.
Но есть и другое, более важное соображение: следует избегать дублирования логики. Определенно нехорошо дублировать логику синтаксического анализа дат, чтобы избежать исключений. К сожалению, в Java нет методов TryParse(), которые можно найти в .NET Framework, которые позволяют использовать логику синтаксического анализа фреймворка для тестирования на вменяемость без исключений.
В таких случаях я бы предпочел использовать исключения, если только профайлировщик не определил их как узкое место производительности. Но для более простых тестов (nulls, end of file) я бы настоятельно не использовал исключения в качестве замены предложений if.
При выбрасываемом исключении стек сообщений копируется в новый объект Exception, чтобы включить отладку и печатьStackTrace(). Это дорого.
Если ваши in-then получают чрезмерный ухопот, рассмотрите шаблоны управления потоком, такие как шаблоны Strategy, State и Command.