Какое общее правило, когда использовать try catch? [дубликат]

#алгоритм #try_catch

    На данный вопрос уже ответили:
    
        
            Грамотное использование try-catch
                
                    4 ответа
                
        
    
    
На собеседовании мне задали вопрос, какое есть общее правило, когда делать try и catch.
Я ответил, когда есть работа с внешними ресурсами, где возникновение ошибки не зависит
от программиста. Например, когда есть работа с файлами или БД (файл может не существовать,
на диске может закончиться место, коннект к БД может не пройти)
Ответ оказался не полным.

Якобы есть какое-то правило, когда нужно использовать try catch

Сам я склоняюсь к тому, что правильный ответ: использовать try catch надо, когда
нельзя обойтись проверками if/else
А что думаете вы? Какой правильный ответ?

Вопрос касается любого языка.
    

Ответы

Ответ 1

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

Моё мнение: нужно ловить исключение в том месте, где вы знаете, что с ним делать.

Поясню.

Допустим, у вас есть функция открытия файла, файла не нашлось, и она выбрасывает
исключение. Что делать в этой точке?

Это важная операция, без информации из файла продолжать нельзя, так что нужно проинформировать
пользователя и завершить программу? Или это файл конфигурации, которого в начале работы
программы нету, и его нужно будет создать с данными по умолчанию?

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

Такая одноуровневая схема может оказаться слишком простой, и вам придётся на пути
перепаковывать исключение, добавляя в него смысла. Например, при чтении числа из строки
произошло исключение из-за несоответствия формата. Вы в этой точке не знаете, фатальна
ли эта проблема, и просто пропускаете исключение дальше. Логика более высокого уровня
знает, что происходит операция чтения конфигурационных данных, которая почему-то завершилась
с исключением. В этой точке логика программы имеет возможность решить, что игнорировать
проблему нельзя, и она бросает более высокоуровневое исключение, которое означает «чтение
конфигурации завершилось аварийно». Это исключение, в свою очередь, ловит бизнес-логика
верхнего уровня, которая сообщает юзеру о потере конфигурационного файла и пересоздаёт
его заново.

В любом случае, преждевременный отлов исключений на слишком «внутреннем» уровне вреден,
потому что программа в такой точке обычно не может сделать ничего разумного.


Ответ 2

Вопрос именно так стоит? try и catch? Не исключения вообще?

Тогда - там, где возможна генерация исключения, которое может быть разумно обработано
вашим кодом. Если исключение не может быть сгенерировано - try/catch ни к чему :) Если
вы не можете его обработать - тоже нет смысла его ловить, лучше передать дальше.