LINUX.ORG.RU

В очередной раз об ущербности ПоХаПэ


0

1

Имеем 2 файла:

test1.php:

<?php

function t2h($txt) {
    return htmlspecialchars($txt, ENT_QUOTES, 'UTF-8');
}

// Error handling code
function exceptionHandler($e) {
	echo "<p><font color=\"red\"><pre>Error:<br />".t2h(print_r($e, true))."</pre></font></p>";
	exit;
}
set_exception_handler("exceptionHandler");

function exceptionErrorHandler($errno, $errstr, $errfile, $errline) {
	throw new ErrorException($errstr, $errno, 1, $errfile, $errline);
}
set_error_handler("exceptionErrorHandler");

if (!session_id()) session_start();

try {
	$mbox = @ imap_open('{imap.gmail.com:993/imap/ssl}', 'sa43sosafoei9asdf9ds@gmail.comm', '9jfoihoasjdf');
} catch (Exception $e) {
	echo "Exception!";
}

?>

test2.php:

<?php

if (!session_id()) session_start();

?>

OK

Username/Password для imap_open заведомо неправильные - пытаюсь написать скрипт проверяющий их правильность перед добавлением в DB. Начальник денег на переделку похапешной поделки в python не выделил, так что продолжаем секс с ущербным недоязыком.

Для начала загружаем test1.php (for ex.: http://localhost/test1.php). Скрипт вроде бы завершился, правда выдал какие то непонятно откуда взявшиеся сообщения не смотря на try ... catch и !оператор сокрытия ошибок! (типичный пример ущербности) @. Это проблема #1: язык не имеет адекватной структуры где все ошибки выдаются в виде exception'а который можно поймать или хотя бы где ф-ции возвращают значение сигнализирующее об ошибке которое опять же можно обработать - даже библиотеки для низкоуровневых языков такое делают. Какие же ламеры писали грёбаный похапэ что он у них просто печатает об ошибке??? Даже на уроках информатики школьников за это ругают!!!

Но это ещё только цветочки. Сообщение можно убрать разными способами.

Выше я писал что «скрипт вроде бы завершился». Но как выясняется завершился он каким то странным образом, либо завершился не до конца. К такому выводу можно придти если попробовать теперь загрузить test2.php (for ex.: http://localhost/test2.php). Браузер выдаст сообщение «Connecting...» и остановится на этом этапе. Connection'а не будет т.к. PHP лочит файлы сессии и оба файла юзают одну и ту же сессию. И, внимание: первый казалось бы завершившийся скрипт либо не разлочил файл сессии либо не завершился до конца!!! в связи с чем второй файл будет ждать разлочки сессии чего похоже никогда не произойдёт. Теперь единственной возможностью загрузить хоть что то использующее эту сессию является перезапуск apache!!!

Что же делать? Закрывать сессию перед этим участком кода? Это поможет если скрипт завершился но забыл закрыть сессию. А что если скрипт остался в памяти? А похоже так оно и есть в связи с тем что перезапуск apache убивает процесс и разлочивает файл.

Мой вердикт: разработчиков убогой поделки расстрелять!!!

Ты в очередной раз открыл фрактал имени Лердорфа.

GateKeeper ★★ ()

PHP

ССЗБ, истеричка.

Deleted ()

Кастани Крона, он говорил что похапе - няша

GoNaX ★★★ ()

Это проблема #1: язык не имеет адекватной структуры где все ошибки выдаются в виде exception'а который можно поймать

Это не проблема языка — это проблема конкретно расширения php_imap. разработчики данного расширения решили, что если программист не озаботился вызвать imap_errors() для получения списка произошедших ошибок, то при уровне ошибок E_NOTICE при завершении запроса (фаза RSHUTDOWN, пользовательский код уже полностью отработал) будут выданы все ошибки.

Варианты: а) error_reporting(E_ALL & ~E_NOTICE); б) проверять, блин, ошибки!!!

sjinks ★★★ ()

Connection'а не будет т.к. PHP лочит файлы сессии и оба файла юзают одну и ту же сессию.

Смотри логи ошибок апача. Много раз с таким сталкивался на CentOS — иноглда из-за апача, иногда из-за APC, часто из-за eAccelerator. Еще из-за Zend Optimizer.

sjinks ★★★ ()
Ответ на: комментарий от sjinks

Огромное спасибо за единственный адекватный ответ, сейчас буду пробовать решить проблему с помощью imap_errors. Кстати говоря, это и проблему с залоченной сессией может решить?

Проблема эта всё таки относится не только к расширению но и к PHP в целом т.к. многие PHP ф-ции так делают - вместо exception'а просто выводят текст сообщения об ошибке ну и '@' это как то костыльно.

tyler19 ()
Ответ на: комментарий от sjinks
# tail -f /var/log/apache2/error_log 
[Sat Feb 02 12:54:12 2013] [warn] child process 12481 still did not exit, sending a SIGTERM
[Sat Feb 02 12:54:14 2013] [warn] child process 12481 still did not exit, sending a SIGTERM
Error in my_thread_global_end(): 1 threads didn't exit
[Sat Feb 02 12:54:15 2013] [notice] caught SIGTERM, shutting down
[Sat Feb 02 12:54:18 2013] [notice] Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/1.0.0g mod_ruby/1.3.0 Ruby/1.8.7(2011-12-28) PHP/5.4.6--pl0-gentoo configured -- resuming normal operations
[Sat Feb 02 12:54:22 2013] [error] [client <server ip>] PHP Fatal error:  Uncaught exception 'ErrorException' with message 'Unknown: Invalid credentials iq7if836802lab.200 (errflg=1)' in Unknown:0\nStack trace:\n#0 [internal function]: exceptionErrorHandler(8, 'Unknown: Invali...', 'Unknown', 0, Array)\n#1 {main}\n  thrown in Unknown on line 0
[Sat Feb 02 13:17:32 2013] [notice] caught SIGTERM, shutting down
[Sat Feb 02 13:17:36 2013] [notice] Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/1.0.0g mod_ruby/1.3.0 Ruby/1.8.7(2011-12-28) PHP/5.4.6--pl0-gentoo configured -- resuming normal operations
[Sat Feb 02 13:17:40 2013] [error] [client <server ip>] PHP Fatal error:  Uncaught exception 'ErrorException' with message 'Unknown: Invalid credentials p10if864211lbl.214 (errflg=1)' in Unknown:0\nStack trace:\n#0 [internal function]: exceptionErrorHandler(8, 'Unknown: Invali...', 'Unknown', 0, Array)\n#1 {main}\n  thrown in Unknown on line 0
[Sat Feb 02 14:21:32 2013] [error] [client 46.180.202.229] invalid request-URI 
tyler19 ()
Ответ на: комментарий от Jackson_

А разве есть достойная альтернатива PHP?

Есть конечно - Python + Pyramid. И не надо цитировать мои сообщения из других тем т.к.:

- это по-тролльски

- моё мнение эволюционирует со временем

tyler19 ()
Ответ на: комментарий от sjinks

Смотри логи ошибок апача. Много раз с таким сталкивался на CentOS — иноглда из-за апача, иногда из-за APC, часто из-за eAccelerator. Еще из-за Zend Optimizer.

Ничего из перечисленного не используется. Gentoo, Apache, PHP.

tyler19 ()
Ответ на: комментарий от sjinks

Как ни странно imap_errors() решило и проблему с залоченной сессией. Огромное вам спасибо что натолкнули на эту мысль, сам бы я долго мучался так как не приходилось работать с этим расширением раньше.

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

tyler19 ()

Говоришь PHP - говно и показываешь кусок отборного говнокода, квинтэссенцию можно сказать лучших техник. Годно.

И таки да, ваш вердик в отношении пейсателя кода выше привести в исполнение.

n00000000 ()
Ответ на: комментарий от n00000000

Говоришь PHP - говно и показываешь кусок отборного говнокода, квинтэссенцию можно сказать лучших техник. Годно.

В чём говнокодность куска кода? Этот кусок как раз таки минимизирован как и рекомендуется всегда делать прежде чем задавать вопрос или показывать баг. Говнокодно как раз таки само расширение в котором ошибки обрабатываются отдельной ф-цией вместо exception'а. Кстати заметьте что отсутствует возможность корректно обрабатывать ошибки при работе с несколькими почтовыми серверами одновременно т.к. imap_errors() возвращает все ошибки, хоть бы resource принимала в качестве аргумента. Говнокодность же PHP как раз таки в этом их подходе, в дуратском операторе @ и выводе ошибок прямиком к пользователю.

Я хочу сказать что задумка PHP была неплоха как высокоуровневый язык для веб приложений с C-подобным синтаксисом. Учитывая ущербность того на чём это делалось до PHP вполне понятно что PHP стал для веб программистов отличным подарком и получил столь бурное развитие. Ущербность же реализации видимо связана с тем что первую версию писал перловщик на перле, они привыкли городить шаткий код. Ну что ж стоило то вместо ущербного вывода в stdout всех ошибок довести до конца поддержку try...catch, exception.

tyler19 ()
Ответ на: комментарий от tyler19

В imap_open намешали всё что только можно, оно и exception создаёт, и в stdout пишет, и false возвращает. Такое ощущение что писали не разобравшись ни в чём до конца, как будто сели пьяные и набросали кое как. Вот этот код работает корректно:

$mbox = false;
try {
	$mbox = @ imap_open($connStr, $newAccount['username'], $newAccount['password']);
} catch (Exception $e) {}
$imapErrors = imap_errors();
if ($mbox === false) {
	$err = "Couldn't establish connection with mail server";
	if (is_array($imapErrors)) $err .= ": ".join(", ", $imapErrors);
	$newAccount_errors[] = $err;
}
tyler19 ()
Ответ на: комментарий от tyler19

Говнокодно как раз таки само расширение в котором ошибки обрабатываются отдельной ф-цией вместо exception'а.

Гуглим дату добавления исключений в php и дату выхода расширения.

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

Толсто.

n00000000 ()
Ответ на: комментарий от n00000000

Хоть толсто хоть тонко, мне пофиг как это называется на луркморье, зато правда. Нагородили монструозную херню вместо элементарного exception'а. Неплохо бы апдейтить время от времени. Да и exception'ы известны давненько уже годов так с 80-х точно.

tyler19 ()
Ответ на: комментарий от n00000000

И вообще почему когда я хвалю PHP на меня тут спускают всех собак и как только не оскорбляют. Начинаю ругать - такая же ситуация. Похоже тут люди только и думают как бы поскандалить и адекватных пользователей ЕДИНИЦЫ.

tyler19 ()
Ответ на: комментарий от tyler19

многие PHP ф-ции так делают - вместо exception'а просто выводят текст сообщения об ошибке ну и '@' это как то костыльно

В этом случае set_exception_handler() спасает. Пока что единственное исключение из правила — php_imap. Кстати, кривизна этого расширения во многом обусловлена кривизной библиотеки c-client (реализация IMAP от UW).

sjinks ★★★ ()
Ответ на: комментарий от tyler19

Error in my_thread_global_end(): 1 threads didn't exit

my_thread_global_end() — это из libmysqlclient; возможно, что где-то выполняется долгоиграющий запрос или висит транзакция (например, в состоянии Waiting for metadata lock).

sjinks ★★★ ()
Ответ на: комментарий от tyler19

Кстати заметьте что отсутствует возможность корректно обрабатывать ошибки при работе с несколькими почтовыми серверами одновременно

Это ограничение UW c-client — там callback задаётся в глобальной переменной; автор(ы) этой библиотеки явно не предполагали одновременной работы с несколькими ящиками. c-client не развивается, как следствие, ошибки архитектуры исправлять никто не будет. У меня была мысль написать расширение для PHP на основе libetpan, но нет времени :-(

sjinks ★★★ ()

Это пипец. Совершенно очевидно, что ТС на пыхе за всю жизнь выродил ну максимум тыщу строк кода. Сам какой-то бред накатал и теперь указывая на него пальцем нам как-бэ намекает что это не он плохой а похапэ видете-ли.

Твой быдлокод переписывается и сокращается на раз-два если ты хоть раз в жизни слышал про error_reporting и display_errors

ini_set('display_errors', 'off');
error_reporting(E_ALL);
$connection = imap_open('{imap.gmail.com:993/imap/ssl}', 'kfjdkfs@gmail.comm', 'fdsfsd');
if (!is_resource($connection)) die('Ошибочка вышла');
pascal9x ()
Ответ на: комментарий от pascal9x

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

tyler19 ()
Ответ на: комментарий от Dobriy_i_Prostoy

Судя по этому посту ты явно к ним не относишься.

Не тебе судить, флудер.

tyler19 ()
Ответ на: комментарий от sjinks

my_thread_global_end() — это из libmysqlclient; возможно, что где-то выполняется долгоиграющий запрос или висит транзакция (например, в состоянии Waiting for metadata lock).

Выше приведён полный код. Никаким MySQL там и не пахнет.

tyler19 ()
Ответ на: комментарий от sjinks

Это ограничение UW c-client — там callback задаётся в глобальной переменной; автор(ы) этой библиотеки явно не предполагали одновременной работы с несколькими ящиками. c-client не развивается, как следствие, ошибки архитектуры исправлять никто не будет. У меня была мысль написать расширение для PHP на основе libetpan, но нет времени :-(

Авторов таких библиотек под расстрел. Ещё зла не хватает в отношении php curl которому необходим внешний файл для сохранения cookie что крайне неудобно а так же не безопасно в связи с чем пришлось городить костыльный класс берущий cookie из заголовков.

tyler19 ()
Ответ на: комментарий от tyler19

зла не хватает в отношении php curl которому необходим внешний файл для сохранения cookie

Опять же, все вопросы к автору libcurl — http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTCOOKIEJAR

Почти все расширения PHP — это обёртки над какими-то библиотеками; как следствие, ущербность API во многом определяется возможностями этих библиотек.

sjinks ★★★ ()

В очередной раз об ущербности БыДлОкОдЕрОв

ritsufag ★★★★★ ()

Выпердышь опять вылез. Ты сначала, прежде чем что-то говорить, думать научись.

VirRaa ★★★ ()

Скрипт вроде бы завершился, правда выдал какие то непонятно откуда взявшиеся сообщения не смотря на try ... catch и !оператор сокрытия ошибок! (типичный пример ущербности) @. Это проблема #1: язык не имеет адекватной структуры где все ошибки выдаются в виде exception'а который можно поймать или хотя бы где ф-ции возвращают значение сигнализирующее об ошибке которое опять же можно обработать - даже библиотеки для низкоуровневых языков такое делают. Какие же ламеры писали грёбаный похапэ что он у них просто печатает об ошибке??? Даже на уроках информатики школьников за это ругают!!!

ошибка в коде ДНК. Ты когда хочешь попасть из пункта А в пункт Б тоже просто тупа туда бежишь? Потом плачешь, что голову об стену разбил? Не? Ты ещё глазки зажмурил(@), чтоб стены не видеть? А на что тебе глазки?

Надо было просто сначала проверить что там с почтой, а потом уже с ней работать.

И, внимание: первый казалось бы завершившийся скрипт либо не разлочил файл сессии либо не завершился до конца!!! в связи с чем второй файл будет ждать разлочки сессии чего похоже никогда не произойдёт. Теперь единственной возможностью загрузить хоть что то использующее эту сессию является перезапуск apache!!!

ага. Это называется «мама, роди меня обратно!». Действительно, голову можно разбить с самыми разнообразными последствиями, вплоть до летального исхода.

Если ты хочешь стать каскадёром, и биться головой апстену, то да, выбивай денег на каску^Wпитон. Тогда можешь биться.

drBatty ★★ ()
Ответ на: комментарий от tyler19

Проблема эта всё таки относится не только к расширению но и к PHP в целом т.к. многие PHP ф-ции так делают - вместо exception'а просто выводят текст сообщения об ошибке ну и '@' это как то костыльно.

да. Это можно назвать «проблемой». На многих стройках тоже надо ходить в каске, ибо на бошку что-то упасть может. Проблема в том, что иногда и каска не помогает (с таким стилем обработки ошибок тебе _любой_ ЯП не поможет, ты всё равно убьёшься. Причём на твоём любимом пайтоне это будет больнее, ибо не сразу)

drBatty ★★ ()
Ответ на: комментарий от tyler19

И всё же это плохое место языка. Происходит непонятно что. Скрипт как бы завершился и как бы нет

тебе уже сказали: это не проблема ЯП, а проблема расширения imap. вот, доку прочитай: http://php.net/manual/ru/book.imap.php У меня когда-то была такая проблема, я её решил за 10 минут - даже идиот догадался-бы, что надо заюзать imap_errors(), и только питонист стал катить бочку на ЯП.

drBatty ★★ ()
Ответ на: комментарий от border-radius

Даже брейнфак достойней PHP, несмотря на скудный I/O.

ну давай в студию свой код imap_open, посмотрим, чем он круче php::imap_open().

drBatty ★★ ()
Ответ на: комментарий от tyler19

Похоже тут люди только и думают как бы поскандалить и адекватных пользователей ЕДИНИЦЫ.

ты на себя посмотри: вместо того, что-бы нагуглить функцию обработки ошибки, ты создал тему на лоре «как хреново пхп обрабатывает ошибки».

drBatty ★★ ()
Ответ на: комментарий от tyler19

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

Если твои скрипты выводят пользователю ошибки - это неопровержимое доказательство того, что серьёзных сайтов (или другого софта) на пыхе ты никогда в жизни не делал.

Ответь мне пожалуйста на такой вопрос: зачем пользователю сайта (или пусть даже консольного приложения) видеть хрен пойми какие ошибки? Да ещё и раскрывать серверные пути.

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

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

О да, сейчас конечно попрут комменты «покажи мне хороший софт на похапэ». Да пожалуйста: mediawiki, vbulletin, wordpress и куча другого нужного софта.

Ну и напоследок: прежде чем троллить вышеперечисленное покажите что вы (или хотябы кто-то другой) можете лучше.

pascal9x ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.