Разговор с одним из разработчиков навел меня на мысль, что иногда программисты путают «обработку ошибки» и «предотвращение ошибки». Т.е. вместо того, чтобы «не делать» ошибки (особенно если известна причина ее возникновения) пытаются дождаться исключения и обработать его.
Ловкое использование блоков try...catch ведет вовсе не к повышению стабильности работы программы, а скорее к запутыванию логики. Исключение говорит нам о том, что программа работает не так, как ожидалось, и нужно понять причину.
Возникает вопрос – когда же есть необходимость использовать try...catch, а когда стоит отказаться от такой конструкции. Для себя я выделяю следующие варианты использования try...catch:
- Документированная функциональность. Т.е. фактически сказано, что обращение к тому или иному методу может вызвать исключительную ситуацию.
- Невозможно отследить ошибку и понять ее причину. Т.е. нужно просто закрыть баг.
Использование try...catch «не по назначению» может свидетельствовать о том, что разработчик не понимает логики функционирования отдельных частей своей программы (или не хочет понимать).
На мой взгляд, не нужно перехватывать такие исключения как «NullPointerException» и «Null object reference», если есть возможность это предотвратить. Конструкция try...catch работает гораздо медленнее прямой проверки. Приведем простой пример – сравнение try...catch с if...else. На этом примере видно, что try...catch работает на порядок медленнее.
В статье приведен пример «неудачного» использования перехвата исключений – try...catch в 2000 раз медленнее (но это у же на Flash
).
Каждый для себя может решить – когда стоит использовать try...catch, а когда стоит задуматься над логикой и написать пару лишних условий-проверок, но факт остается фактом “Exceptions are for exceptional situations". А try...catch лишь способ как то контролировать исключительные ситуации.
Recent Comments