BFE>Это ошибочный подход из-за "многопоточности". Файл в любой момент может быть удалён кем-то ещё, поэтому проверка что-либо до вызова функции не гарантирует, что в момент вызова функции файл всё ещё будет существовать.

"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации).

"Файл в любой момент может быть удалён кем-то ещё" больше походит на описание как раз исключительной (обрабатываемой исключениями) ситуации. Если это ожидаемая ситуация — тогда эти исключения придется либо (так себе вариант) ловить на КАЖДОЙ файловой операции отдельно (в т.ч. и после нашего сравнения, если предусмотрены дальнейшие действия над уже сравнёнными файлами), либо (проще и логичнее) завернуть в один try...catch всю группу операций (более широкую, чем наше сравнение) — и для второго варианта как раз лучше, чтобы в операции сравнения своей обработки исключений (ситуации отсутствия файлов) не было.

Из предложенных вариантов, попробую угадать, (г) (со ВСЕМИ заранее реализованными вариантами реакции на отсутствие файлов) оказывается более приемлемым?

BFE>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).
BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.

BFE>Кстати! Добавление исключения в функцию — это ведь как раз попытка написать универсальный код, особенно если эти исключения не будут задействованы.

На всякий случай: у меня о ДОБАВЛЕНИИ исключения в функцию речь не шла, проброска исключений из вызываемых функций выше (в вызывающую) не требует кода.

BFE>Это ошибочный подход из-за "многопоточности". Файл в любой момент может быть удалён кем-то ещё, поэтому проверка что-либо до вызова функции не гарантирует, что в момент вызова функции файл всё ещё будет существовать.

"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации/забывчивого программиста).

"Файл в любой момент может быть удалён кем-то ещё" больше походит на описание как раз исключительной (обрабатываемой исключениями) ситуации. Если это ожидаемая ситуация — тогда эти исключения придется либо (так себе вариант) ловить на КАЖДОЙ файловой операции отдельно (в т.ч. и после нашего сравнения, если предусмотрены дальнейшие действия над уже сравнёнными файлами), либо (проще и логичнее) завернуть в один try...catch всю группу операций (более широкую, чем наше сравнение) — и для второго варианта как раз лучше, чтобы в операции сравнения своей обработки исключений (ситуации отсутствия файлов) не было.

Из предложенных вариантов, попробую угадать, (г) (со ВСЕМИ заранее реализованными вариантами реакции на отсутствие файлов) оказывается более приемлемым?

BFE>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).
BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.

BFE>Кстати! Добавление исключения в функцию — это ведь как раз попытка написать универсальный код, особенно если эти исключения не будут задействованы.

На всякий случай: у меня о ДОБАВЛЕНИИ исключения в функцию речь не шла, проброска исключений из вызываемых функций выше (в вызывающую) не требует кода.