BFE>Да, я видел такой подход. Такой подход ведёт к тому, что при всех подобных вызовах (и это не обязательно работа с файлами), код поимки исключения добавляется при каждом вызове функции и обрабатывается одинаково. Как если бы это было просто третье значение возвращаемое функцией.Выглядит нечитаемо и приводит к дублированию кода по всему проекту.

Если ситуация отсутствия хотя бы одного из файлов ПРЕДУСМАТРИВАЕТСЯ общей задачей, то логичнее проверить их наличие ДО вызова функции сравнения и соответственно среагировать (и это будет ветвление, а не обработка исключения). Если не предусматривается — то дефолтный обработчик всех необработанных никем исключений — как раз адекватное место для реакции на НЕпредусмотренные ситуации.

BFE>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?

Возможна масса вариантов, зависящих от общей задачи:
а) ситуация отсутствия файлов предусматривается, является ошибкой конфигурации/интеграции/пользователя и должна быть обработана ДО сравнения — тогда не обрабатывать исключения в сравнении, пусть они сигнализируют об ошибке ПРОГРАММИСТА (забывшего заранее обработать ситуацию)
б) ситуация отсутствия файлов НЕ предусматривается (невозможна/невероятна) — опять же не обрабатывать исключения в сравнении, пусть они сигнализируют об ИСКЛЮЧИТЕЛЬНОЙ ситуации
в) ситуация отсутствия файлов предусматривается, при этом отсутствующий файл можно рассматривать как неотсутствующий (пустой и т.п.) — эту ситуацию другие комментаторы уже рассмотрели, не буду углубляться, т.к. вариантов всё равно больше одного.
г) никакой общей задачи нет, наше ТЗ — на шарообразную функцию в вакууме — тогда для УНИВЕРСАЛЬНОСТИ придется ввести третий входной параметр, в котором будет enum из всех возможных вариантов обработки ситуации несуществования файлов, и все эти варианты реализовать.

BFE>Я не следую принципу YAGNI, так как этот принцип ведёт к написанию исключительно ситуативного кода и как следствие к нулевому переиспользованию. Мне просто не интересно писать такой код.

Принцип YAGNI призван экономить время программиста (ну не получается заранее ВСЁ предугадать и написать УНИВЕРСАЛЬНЫЙ код; попытки его таки написать отнимают кучу времени сейчас и вовсе не гарантируют экономии времени в будущем). Сделать программирование интересным — это другая задача, с задачей экономии времени она слабо пересекается.

BFE>Да, я видел такой подход. Такой подход ведёт к тому, что при всех подобных вызовах (и это не обязательно работа с файлами), код поимки исключения добавляется при каждом вызове функции и обрабатывается одинаково. Как если бы это было просто третье значение возвращаемое функцией.Выглядит нечитаемо и приводит к дублированию кода по всему проекту.

Если ситуация отсутствия хотя бы одного из файлов ПРЕДУСМАТРИВАЕТСЯ общей задачей, то логичнее проверить их наличие ДО вызова функции сравнения и соответственно среагировать (и это будет ветвление, а не обработка исключения). Если не предусматривается — то дефолтный обработчик всех необработанных никем исключений — как раз адекватное место для реакции на НЕпредусмотренные ситуации.

BFE>Предположим, что вы пишите ТЗ. Какое уточнение вы добавите?

Возможна масса вариантов, зависящих от общей задачи:
а) ситуация отсутствия файлов предусматривается, является ошибкой конфигурации/интеграции/пользователя и должна быть обработана ДО сравнения — тогда не обрабатывать исключения в сравнении, пусть они сигнализируют об ошибке ПРОГРАММИСТА (забывшего заранее обработать ситуацию)
б) ситуация отсутствия файлов НЕ предусматривается (невозможна/невероятна) — опять же не обрабатывать исключения в сравнении, пусть они сигнализируют об ИСКЛЮЧИТЕЛЬНОЙ ситуации
в) ситуация отсутствия файлов предусматривается, при этом отсутствующий файл можно рассматривать как неотсутствующий (пустой и т.п.) — эту ситуацию другие комментаторы уже рассмотрели, не буду углубляться, т.к. вариантов всё равно больше одного.
г) никакой общей задачи нет, наше ТЗ — на шарообразную функцию в вакууме — тогда для УНИВЕРСАЛЬНОСТИ придется ввести третий входной параметр, в котором будет enum из всех возможных вариантов обработки ситуации несуществования файлов, и все эти варианты реализовать. (Если ЯП позволяет — можно задать дефолтное значение для параметра и можно будет его не прописывать в вызове.)

BFE>Я не следую принципу YAGNI, так как этот принцип ведёт к написанию исключительно ситуативного кода и как следствие к нулевому переиспользованию. Мне просто не интересно писать такой код.

Принцип YAGNI призван экономить время программиста (ну не получается заранее ВСЁ предугадать и написать УНИВЕРСАЛЬНЫЙ код; попытки его таки написать отнимают кучу времени сейчас и вовсе не гарантируют экономии времени в будущем). Сделать программирование интересным — это другая задача, с задачей экономии времени она слабо пересекается.