@Stranger_

Понимаю, что из названия темы мало, что понятно. Постараюсь объяснить на примере. Ситуация такая, пишется обработчик запроса с какого-то внешнего устройства (магазинная касса). Обработчик - скрипт на чистом PHP, без использования фрейморков. Он выполняет минимально необходимые действия по обработке запроса. И после этого должен вызвать другой скрипт, который лежит на этом же сервере, просто в другой директории. Этот второй скрипт работает под управлением фреймворка. Смысл в этом такой, что при ошибках в фреймворке API для касс продолжит работать, просто с чуть подрезанным функционалом. Не нужно меня спрашивать, зачем так делается и почему. Условимся, что это требование заказчика.

Так вот, я хотел поинтересоваться, как лучше всего организовать вызов этого второго скрипта? Пока мы остановились на варианте с cURL. Но что-то у меня на душе неспокойно.

0

@cheshirskydimk

Ну, как вариант, вызов с помощью system()

1

@ads

пейте успокоительное.достаточно include, require и иже с ними.

0

@Stranger_

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

То есть, ты имеешь ввиду запустить php из командной строки и в качестве параметра передать второй скрипт? А чем он лучше cURL?

0

@cheshirskydimk

Ну а зачем тут курл, если можно изнутри сервака обратиться?

0

@Stranger_

Как например?

0

@cheshirskydimk

Я про систем()

Добавлено через 48 секунд
Ну и вообще, что смущает и в том и в том варианте?

0

@Stranger_

В варианте с system смущает момент, как в первоначальный скрипт вернуть http код ответа страницы? А в варианте с cURL смущает ощущение, что иду к соседнему дому через северный полюс

0

@cheshirskydimk

Ну а если вместо заголовков вернуть структурированный к-либо образом ответ "http status, данные"?

0

@Stranger_

Допустим. А в этом случае не будет запущено две копии интерпретатора PHP?

0

@cheshirskydimk

Если я правильно помню, то каждый запрос запускается отдельным процессом. О каких копиях идет речь?

0

@Stranger_

Не, я имею ввиду, что это будет не запрос к серверу, а обращение к исполняемому файлу. Честно говоря, я не уверен, как это произойдёт в unix, но windows при этом запустит ещё один экземпляр программы. И неясно ещё, закроет ли он её после выполнения скрипта.

0

@Drygba

Зачем выдумывать велосипед?
Делайте, как вам уже посоветовали, include и require и оберните все это try/catch.

1

@cheshirskydimk

Эм. Ну так скрипт отработает и потом процесс завершается

0

@Stranger_

Спасибо. Идея была интересная, но не прокатит. При фатальных ошибках try/catch ничего не отловит. Но появилась идея с перехватом всех фатальных ошибок. Может быть, этот вариант сработает.

Добавлено через 1 минуту
Честно говоря, буду сомневаться до тех пор, пока не попробую. В любом случае за идею спасибо.

0

@cheshirskydimk

Они не отлавливаются. И вообще, почему они должны вдруг случиться?

0

@Stranger_

Вот тут вроде рассказано, как их можно отловить.

Не должны, конечно. Но ситуация примерно такая. У заказчика есть какой-то феерически крутой и надёжный код, в котором вообще исключены ошибки (с его слов, я не проверял). А мы цепляем к нему наши скрипты, которые работают под управлением Bitrix. И вот, заказчик боится, что если сцепить скрипты простым include, то при каких-то ошибках в наших скриптах вся его система рухнет. Поэтому и приходится запускать наши скрипты через такую ж...

0

@cheshirskydimk

Короче, много заморочек по поводу стороннего продукта. Почему надо предусматривать то, что он может выдать ошибку? Ну выдал он ошибку, значит так и сообщим "то-то выдало ошибку, я не могу работать дальше"

0

@ads

достаточно легко отлавливаются.

И наверно не стоит использовать недоделки вызывающие фатальные ошибки. Зачем опускаться на уровень халтурщиков?

0

@cheshirskydimk

Ну хорошо, посмотрел пример, попробовал. Но это не тоже самое, что try-catch.
В трай-каче после ошибки скрипт продолжится, в этом случае - нет. Можно, конечно, велосипедить в функции, заданной register_shutdown_function, но это мы сами понимаем, что.

0