Но это была бы разовая акция, а тут выяснилось, что 40% файлов даже никогда не создаются

Ну в итоге ты заиспользовал исключения не там где надо

Понятно

Пусть будет так

Просто файл могут потереть непосредственно перед началом чтения ...

Это никак не контролировалось и обработка этого исключения все равно осталась

Просто хотел привести пример, что try catch это не серебряная пуля позволяющая положить болт на ненужные проверки ..

Ну в этом случае мне кажется и так очевидно что нужно было проводить проверки как минимум существует ли файл по такому пути и не пустой ли он, конечно сделать что то типа if(file.IsExist()) будет производительней

В первоначальной постановке задачи про подводные камни никто не говорил)

Просто все сводится к тому, что try catch надо юзать только там, где нельзя предотвратить исключение, обратное ведет к просадкам по призводительности

Try catch нужно ставить там, где может возникнуть ИСКЛЮЧИТЕЛЬНАЯ СИТУАЦИЯ, которую ты не можешь предвидеть, и предусмотреть

То есть если везде null и мы боимся налрефа, то как бы код плохо написан, или это дто, и надо проверять естественно объект к которую обращаемся.

Часто вообще на null логику вешают

А как правильно передать вызывающему коду то что внутри что то пошло не так, например есть юзер и у него есть баланс и он через интерфейс пытается снять деньги и вводит количество которое превышает его баланс и в методе withdraw соответственно не получится снять количество которого нету, что тогда делать, вызывать исключение и перехватывать в вызывающем коде или делать так что бы метод возвращал какой то объект успешности операции, получилось ли снять или нет?

Делать проверки, А не ловить исключения

Ну я об этом и спрашиваю, в методе withdraw мы получили ответ от бд о балансе и проверили и поняли что баланса не достаточно, как правильно передать это вызывающему коду интерфейса что бы он отобразил оповещение об недостаточном балансе

Как вариант обернуть в класс контейнер с полем например СтатусОперации, Коментарий и при выполненой операции ставить статус true, а при ошибке статус false, а потом уже обрабатывать этот ответ

Погугли Result<TResult,Error>
Это как вариант
И Try pattern

И в итоге что? На простом коде понятно, но стоит коду вырасти, то концов не свести будет...

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

Вот эти коды ошибок с энам, это что-то старое... любое расширение будет для вас болью

Хорошо, спасибо