Судя по вопросу, в системе уже стоит как минимум несколько приложений, которые могли это сделать (вряд ли ТС готов поверить, что это сделали фирменные утилиты Самсунга или гугловский Хром).
Тогда, если быть рациональным и оценивать реальные риски - совершенно безразлично, которое из них поставило вам что бы то ни было. Никакие трехбуквенные добавки эту ситуацию уже не испортят.
Если возвращается ссылка, с которой потом предполагается работа как со ссылкой - логично не возвращать нелепую и провоцирующую отложенные ошибки переменную с null-значением, а бросать исключение конкретно там, где проблема (выход за границы массива) имеет место.
Иначе вокруг этой конструкции, как жемчужина в раковине, будет постоянно нарастать говнокод.
"Отправлять книгу" незачем.
Отправляется ссылка на скрипт, который проверяет у клиента факт покупки и выдает нужный файл нужного формата либо отлуп.
В Битриксе сто лет как были реализованы соответствующие механизмы, в т.ч. с ограничением по времени. Копайте.
AlexandrMa, курл - не голубиная почта, это двустороннее соединение. Обрыв его на этой стороне вполне может означать, что сделанный запрос не выполнится вовсе. Кто-то должен держать это соединение, пока удаленный сервер не отработает. При использовании PHP curl этот кто-то - как раз твой скрипт.
Хочешь, чтобы он продолжил работу - запускай курл отдельным процессом, а чтобы эти процессы ненароком не наступали друг на друга - таки организуй им очередь. Никакого оверхеда в этом нет.
Если вызывается свой же скрипт, который тоже запускает курл - можно на его стороне быстро закрыть соединение с первым, это решает поставленную задачу XY, но не меняет ничего в принципе. Все равно один из обработчиков пыха будет занят ожиданием курла. С поправкой на то, что дергать свои же скрипты извне - не только говнокод, но и потенциальная дыра.
Есть теоретическая возможность, что с заголовком "Connection: close" удаленный сервер быстрее ответит "ну ок, закрывайся, раз тебе не надо", но это зависит уже от реализации на той стороне.
Ипатьев, говнокод с exec или односекундным таймаутом гугловская нейросетка выдает выше, чем ссылку на этот вопрос.
Однако сам вопрос, как правило, будет просто следствием ошибки планирования. На что ИИ указать постесняется, а Тостер - нет ;)
toxa82, ему - надо, иначе так и будет говнокодить и бояться лишний раз запустить крон.
Как раз на примитивном проекте проще попробовать правильные подходы - не рискуя ничем.
Для будущего мы встаем ото сна...
И если этот второй скрипт будет валиться с ошибкой на первой же секунде, вы об этом узнаете... никогда.
Кстати, попробуйте угадать, какой версии на вот этом хостинге /usr/bin/php:
Соглашусь. Именно в такой же мамке поменял R5 1400 на R5 5600G без всяких проблем, тут не Интел, который сокеты меняет, как наперстки.
Правда, "одним вечером столкнулся" также может означать, что просто в системе кто-то поселился... винды же, небось?
Можно попробовать отключить временно мониторы от видеокарты.
Возможно, дело не в потере кабелем сигнала, а просто в том, что видюха "теряет" кабель и переключается на то, что осталось.
Telcontar, я бы в этом списке смотрел на две с половиной строчки. IPS, матовый - значит, с экраном ОК.
Заявлена частота в 144 Гц - ну ладно, пусть будет, наверное, правда хорошая матрица ;)
Для разработки в вебе вообще-то вредно иметь профессиональную цветопередачу - она не совпадет с 99% того, что реально увидят в вебе пользователи вашего продукта.
А насчет того, что вам у кого-то кажется слишком блеклым - я бы рекомендовал и свой настроить так же. Настройки экрана "как на прилавке" только глаза портят.
Блеклость или кислотность цветов не имеют никакого отношения к нарисованным попугаям типа "цветового охвата".
Теоретически на более низком охвате на радуге будет меньше оттенков. И только. Вот если там дерьмовая матрица и низкий охват - только один из симптомов этого...
Тогда, если быть рациональным и оценивать реальные риски - совершенно безразлично, которое из них поставило вам что бы то ни было. Никакие трехбуквенные добавки эту ситуацию уже не испортят.