Вычитал, что использование try-catch весьма ресурсоёмко. Так ли это?
Если так, то как следует грамотно использовать try-catch?
Теоретически ведь можно практически всё делать по старинке, через коды возврата, минуя использование try-catch, но тогда код пострадает в плане читаемости из-за громоздких последовательностей if или switch.
Ответ
Для начала определите для себя, что такое «ресурсоёмко». Любой вопрос производительности стоит рассматривать в контексте с производительностью всей остальной программы. Если у вас алгоритм на целочисленной арифметике, то в нём try/catch может заметно замедлять производительность (а может и не замедлять). Если у вас идёт запись в файлы или обращение к базе данных, то обработка исключения будет на порядки быстрее остальных операций, поэтому нет никакого смысла её оптимизировать.
Обычно try/catch нисколько не замедляет программу, если исключений фактически нет. То есть кидая исключение только в случае ошибки, вы не потеряете в производительности, когда ошибок нет. Если же ошибка произошла, то работа вашего алгоритма всё равно будет прервана, поэтому не так важно, что вы один раз потеряете дополнительно пару микросекунд (вряд ли больше) перед выдачей ошибки пользователю.
Вам стоит беспокоиться, только если вы в цикле кидаете миллион исключений, потом их ловите, игнорируете и переходите на следующую итерацию. Но такой код как раз уже попахивает: получается, вы используете исключения для управления потоком вычислений, а не для информирования об исключительной ситуации. Но даже в такой ситуации JIT-компилятор может сообразить. Если в пределах заинлайненного кода он увидит и выбрасывание исключения и поимку и заметит, что при поимке вы игнорируете исключение (в частности, не читаете стектрейс из него), то он потенциально может заменить выбрасывание исключения на обычный goto, не создавая объект исключения вообще. Вообще обычно самое медленное в исключении — это создание стектрейса.
Общее правило: пишите код так, как рекомендуют авторы языка и признанные специалисты в данной области. Если производительность кода вас не устраивает, профилируйте его, находите узкие места и оптимизируйте именно их (возможно, отступая от красоты кода в угоду скорости). Но не оптимизируйте то, что занимает полпроцента от общего времени выполнения. Не надо оптимизировать преждевременно.
Комментариев нет:
Отправить комментарий