В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

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

Все зависит от сценария. Как я уже писал выше, в большинстве сценариев мы вообще ничего не пишем.

Напрягитесь, придумайте хотя бы парочку, и я напишу вам как с ними работать.

FanatPHP, а если так? ))))
@file_get_contents()

Евгений, в этом случае все просто - отрезать руки и засунуть туда, откуда они растут

FanatPHP, я приводил пример с файлом не потому что мне нужен файл, а потому что это первое что в голову пришло из банального :)
Посмотрите, пожалуйста, ветку комментариев к ответу от Daria Motorina, я там достаточно подробно объяснил почему у меня возник этот вопрос и ответ какого рода я ищу.
Вы просили сценарий - например такой: требуется создавать файл с дефолтным содержимым если его нет и сразу отдавать. Пример опять же исключительно иллюстрационный

f getFileContent(path){
    if (!File::isExist(path)) {
        file = new File(path);
        file.put("This is something default");
        file.save();
    } else {
        file = File::fromPath(path)
    }
    return file.content;
    return file_content(path)
}

# Вариант 2:
f getFileContent(path){
    try {
        file = File::fromPath(path)
        return file.content;
    }
    catch FileNotFoundException {
        file = new File(path);
        file.put("This is something default");
        file.save();
        return file.content
    }
}

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

Но ведь автор
Во первых не кидает никаких исключений.

Во вторых в обоих случаях не выходит за пределы логики функции - исключение ловится в getFileContent и не уходит выше.

Так какой вариант обработки необходим здесь?

Михаил Братеньков, в примере не вполне понятно: {error: file not found} это выброс ошибки или уже её обработка?

Оба варианта плохие тем, что скрывают причину облома внутри и надеются на пользователя этой функции, который по возвращённому пустому значению поймёт, что что-то пошло не так.

Сергей Соколов, обработка.

Продублирую расширенный пример который привел автор вопроса в соседней ветке. Цель - в случае если файл не существует создавать, наполнять содержимым и возвращать его, если существует - просто возвращать

f getFileContent(path){
    if (!File::isExist(path)) {
        file = new File(path);
        file.put("This is something default");
        file.save();
    } else {
        file = File::fromPath(path)
    }
    return file.content;
    return file_content(path)
}

# Вариант 2:
f getFileContent(path){
    try {
        file = File::fromPath(path)
        return file.content;
    }
    catch FileNotFoundException {
        file = new File(path);
        file.put("This is something default");
        file.save();
        return file.content
    }
}

Михаил Братеньков, 1-й вариант лучше (закрываю глаза на два return подряд), т.к. отсутствие файла и необходимость создать дефолтный – штатная ситуация в логике приложения.

Сергей Соколов, объясните подробнее как определить является ли ситуация штатной или нет. Разве сам факт наличия в коде try{...}catch{...} не говорит о том что ситуация является штатной? Или он говорит о том что разработчик допускает возможность возникновения такой ситуации, но при этом не считает её нормой?

Если нет то верно ли понимаю что в блоке catch по определению должна быть описана логика сообщения об ошибке пользователю или разработчику? А если мы хотим что-бы отлов подобных ситуаций и их обработка происходила автоматически без участия людей (как в примере выше) то должны использовать вариант с if?

Сергей Соколов, это расуждение очень хорошо подтверждает мысль что деление ситуаций на "штатные и нештатные" является очень условным и служить критерием не может

Есть кейсы, когда один подход может заменить другой. На примере из комментария к ответу выше:

# Вариант 1:
f getFileContent(filename){
if (!file_exists(filename)) {error: file not found}
return file_content(filename)
}

# Вариант 2:
f getFileContent(filename){
try return file_content(filename)
catch FileNotFoundException {error: file not found}
}

Чего следует придерживаться в PHP?

Олег Правдин, если file_exists бросает исключение, то проверка ее возврата на false ничего не даст, возврат false это штатная ситуация, а исключение - нештатная

Daria Motorina, В данном примере я рассматриваю file exists как булевую функцию. True если файл на месте и false если его нет.
Вопрос именно подходе к реализации. Python придерживается принципа EAFP, а какой из паттернов согласуется с идеологией PHP?

Олег Правдин, в php такого паттерна нет, и странно ожидать от php поведения python, если это другой язык. Вы же не ожидаете поведения java от javascript или поведения clojure от haskell, потому что Вы считаете, что какой-то из пары языков описан лучше - только документация по php описывает php. Какая разница, булевая функция или другая, если есть одно условие - бросается в ее теле исключение или нет? Бросается - ловите, не бросается - не ловите

Daria Motorina, паттерн в моем понимании - не зависящая от языка вещь. Просто идея для реализации чего-то по определенной схеме с какими-то логическими частями, которые как-то между собой взаимодействуют. Тот же MVC по сути это просто идея, реализовать которую можно на многих языках. В данном случае я привел 2 паттерна, оба реализуемы на PHP.
Вопрос по поводу "как делать лучше, когда можно сделать и так и эдак". Какой-то coding style или что-то в этом духе. Я привел в пример Python не потому что я ожидаю от PHP поведение Python, а потому что там когда-то сказали "Эгегей, товарищи, давайте придерживаться принципа, что у нас easier to ask for forgiveness than permission". Это не значит, что нельзя делать иначе, просто эта рекомендация и отправная точка для членов сообщества. Тот же PEP8 содержит рекомендации, как называть классы, методы, свойства. Он не заставляет, он направляет и вносит единообразие в кодовую базу разработчиков.
Именно такие ориентиры я и ищу в современном сообществе PHP - как делать лучше, как принято. Свой стиль я всегда успею придумать, но я предпочел бы не изобретать велосипед, а использовать общую практику, чтобы мой код был читаем для остальных, а
В данном примере я сначала могу могу проверить существование файла (и как-то это обработать, например создать новый файл с дефолтным текстом) и когда я буду уверен в том, что файл есть - я его прочитаю. Это вариант реализации 1.
А еще я могу вызвать чтение файла в блоке try и все, что я могу обработать - я кину в catch (например то же самое FileNotFoundException - создаю новый файл со стандартным текстом и отдаю его содержимое)

огда я буду уверен в том, что файл есть -

Это заблуждение. См. мой дополненный ответ