Pull to refresh

Comments 48

т.е. Вы подразумеваете что фреймворк должен сообщать Вам об ошибках в настройке вашего мускля?
Он должен был вывести ошибку, а не тихо промолчать.
Это типичный говнокод:
catch(Exception $e)
{
   return false; // !
}
Вы всегда выводите ошибки в ваших функциях для автодополнения полей?
При чем здесь автодополнение полей?
Потратив несколько часов на вставку var_dump-ов и отслеживания путей выполнения, я произвёл изучение следующих мест:

советую Вам потратить пол часа на изучение и настройку xdebug с Вашей IDE
вместо траты «часов с var_dump» хватит 3 минут пройтись по коду пошагово
вы дебажили фреймворки?
дебажил и не раз,
зачастую когда садишься за чтото новое, очень полезно пройтись пошагово от index.php хотя бы до экшена контроллера
Мне ни разу за 3 минуты не удавалось пройти код пошагово :)

В любом случае, изначально пост не о том, кто как дебажит, а как обрабатывается исключение в конкретном месте конкретного фреймворка.
С Yii частенько приходилось вооружаться xDebug-ом, особенно на старых проектах.
само собой, xdebug необходим.
Но, продебажить весь фремворк до какого-либо action, учитывая, что по пути может сработать несколько behavior — довольно утомительное занятие. Я ещё Zend пытался подебажить. Чуть не уснул, пока до action не добрался.
К счастью, всегда можно поставить брекпоинт :)
Только зачем вы адресовали этот коммент мне?
Я подразумеваю что это было бы неплохо.
Не об ошибках в настройках mysql, а о причинах почему определённая операция завершилась с исключением (в режиме отладки конечно).

Обычно SamDark отвечает в постах проYii.
Думаю, этот пост тоже не оставит без внимания
Пост тянет на название: «Я новичок в похапе, взял один из мощных фв и вот скажу какой он плохой, т.к. я сам не настроил mysql» :D автор не смешите...)
Я не говорил что фреймворк плохой, а поделился опытом. Надеюсь кому-то это облегчит жизнь.
Опа :) Подумаю, как бы лучше отображать ошибки в этом случае.
Кстати, спасибо Вам за перевод документации. Интересно =)
Можно еще сказать, спасибо, и за разработку. Александр член core team Yii.
Вот ответ не мальчика, но мужа.
Никаких препирательств — есть ошибка — исправим.
Вообще «Can't create/write to file '/root/tmp/» должна была валиться в лог ошибок php при выполнении запроса в mysql, не искали там? А дальше подключившись к обработчику ошибок mysql можно было бы и увидеть откуда у нее ноги растут (debug_back_trace хотя бы).
Посмотрел только сейчас =(
Здесь "/var/log/apache2/error_log" не нашёл записей с похожими формулировками.
Отсюда 2 вопроса — логи ошибок php у Вас пишутся? И если да, то точно в /var/log/apache2/error_log?
Просто если у Вас временная директория не настроена в mysql, то возможно и с записью ошибок какой-то косяк.
Логи туда пишутся. Например есть запись от вчерашнего числа:
«PHP Warning: htmlspecialchars(): charset `utf8' not supported»
Но записи нет. Возможно и косяк где-то присутствует.
В любом случае, спасибо за наводку. Изучу вопрос подробнее.
ну в debug режиме yii выводит отличный trace — только иногда обрезает код на самом интересном. Но это уже мелочи.
К чему это здесь? Теперь на пост на хабре заменяет issue?

Сунулись бы сюда для начала.
больше года использую yii, почти всегда пользуюсь gii, не разу не сталкивался с подобной проблемой. Новичкам «везёт» :)
Еще к слову о говнокоде:

Если функция возвращает boolean, то не нужно писать так:

while(($row=$dataReader->read())!==false)


А нужно писать так:

while($row=$dataReader->read())
false возвращается только в случае если ридер уже не может что-то вернуть. Если ридер вернет вам ноль, то первый вариант отработает, а второй нет.
А теперь смотри сюда, дружок:
CDbDataReader#read-detail

И на заметку тебе:
Если функция может вернуть как 0, так и false, то значит с ней что-то не так.
BIF'ы в php это отдельная тема для разговора. Если выйти из контекста php касательно 'Если функция может вернуть как 0, так и false, то значит с ней что-то не так', то я тебе скажу, что, например, в любом другом языке(навскидку хоть javascript, python или ruby), аналогичные строковые функции не возвращают boolean. Это просто нонсенс.

Спасибо, дружок!
Я бы не стал называть приведённый кусок говнокодом. Просто дополнительная предосторожность, быть может полученная, из опыта программирования в PHP.

Если метод может вернуть хоть что-то, кроме boolean, то лучше проверить излишне строго сейчас, чем потом неуловимые искать баги. Даже, зная, что этот кусок кода возвращает массив, то лучше проверить строго, потому что пустой массив жуглиться в ложь. Конечно, трудно представить, чтобы в результате запроса можно получить набор пустых массивов, но…

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

Что же касается вопроса «так, не так», так это вопрос спорный. Мне уже трудно об этом судить — я привык. Но хочу чтобы Вы предложили лучший вариант в таких случаях.

Допустим есть координатный отрезок [-64,64] и точка, которая не принадлежит этому отрезку (и даже прямой, на которой лежит этот отрезок). Что должна вернуть функция getPoint(), в таком случае?
В таком случае должен быть еще метод вроде hasPoint():bool, который проверяет находится ли точка в заданом отрезке, а сам метод getPoint() должен создавать исключение при попытке взять точку вне отрезка.
ммм… Кстати, да. Таким подходом я и сам пользуюсь. Но не всегда.

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

Так же модифицируется и работа с интерфейсом.

Вместо
while(($row=$dataReader->read())!==false)
...

получим что-то типа:
while($dataReader->hasData()){
    $row=$dataReader->read();
...
}

Что делает общение с интерфейсом многословнее. Но тут уже дело вкуса.

Хотя можно было бы сделать и так
while($dataReader->hasData() && $row=$dataReader->read();)
...


И так тоже многословнее.
Допустим есть координатный отрезок [-64,64] и точка, которая не принадлежит этому отрезку (и даже прямой, на которой лежит этот отрезок). Что должна вернуть функция getPoint(), в таком случае?


А собственно что должна делать функция getPoint()?
Если тебе нужно узнать, принадлежит ли твоя точка отрезку, то тут ожидается получить true или false. В противном случае она должна вернуть null, nil… что угодно, только не false.

Такая же телега и со строковыми функциями. Если я хочу найти вхождение подстроки в строку(в php считай strpos), я ожидаю, что мне вернется null,nil или -1(если строка может рассматриваться как упорядоченный массив символов). Примерно так это работает в javascript, ruby и python.

Вот вы, господа минусующие(дружки): я конечно понимаю, что делая сайтики на php, вы мыслите совершенно другими категориями). Но приведите мне пример ПОЛЬЗОВАТЕЛЬСКОЙ ФУНЦИИ, в которой реально была бы необходимость возвращать как 0, так false.
Если я хочу найти вхождение подстроки в строку(в php считай strpos), я ожидаю, что мне вернется null,nil или -1

Не знаю. Должно быть это дело привычки. Хотя действительно, при невозможности вычислить результат можно и null возвращаеть. Но для пользователя таких конструкций положение дел не изменится. Это будет тоже, но другое специальное значение, которое надо будет так же специально проверять. «null,nil или -1» — это специальные значения.

Получим что-то типа этого:
while(($row=$dataReader->read())!==null)
while(($row=$dataReader->read())!==nil)
while(($row=$dataReader->read())!==-1)

по сути тоже самое. Только мне "-1" не нравится. Потому что это специальное значение для особых случаев, для других случаев надо будет придумывать что-то другое (как в моём примере), а это уже не общий подход.

Кстати, как выяснилось, у разработчиков PHP null может вернуться из функции, но в других обстоятельствах.

Мне кажется, что Ваше возмущение сводится к «почему в PHP некоторые вещи устроены не так как в некоторых других языках?». Взять хотя бы erlang, которые в некоторых случаях возвращает false в аналогичных ситуациях.
Взять хотя бы erlang, которые в некоторых случаях возвращает false в аналогичных ситуациях.

Пруфлинк, пожалуйста. Во-первых, erlang — не язык общего назначения, и строки там представлены иными структурами. Во-вторых, в эрланге нет булева типа, и true/false там атомы(аналог символов в руби).
Вот, если честно, с этим языком знаком мало. Да, не совсем тип, да, не со строками(я вообще про строки и не говорил), да, это не функция самого языка, а стандартной библиотеки и тем не менее это очень похоже именно на то о чём идёт речь.

keysearch(Key, N, TupleList) -> {value, Tuple} | false
и тем не менее это очень похоже именно на то о чём идёт речь.


Может у нас разное представление о чем идет речь? Я писал о том, что нет необходимости возвращать как 0(нуль), так и false.

В примере же возвращается вполне конкретный tuple.
Возвращается вполне конкретное специальное значение, которое нужно отдельно обработать.
Функция, возвращающая, скажем, количество записей в таблице БД, да вообще количество чего-то. 0 означает, что записей нет или, а false — ошибку при попытке получения количества. Есть и другие способы (пользовательские ошибки, исключения, возврат данных определенного типа, много что можно придумать), но false один из самых простых, немногословных и, главное, привычных php-разработчику.
Функция, возвращающая, скажем, количество записей в таблице БД, да вообще количество чего-то. 0 означает, что записей нет или, а false — ошибку при попытке получения количества.

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

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

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

Ну, я считаю, что у программиста должны быть навыки абстрагирования, а false, как признак ошибки, в функциях стандартных библиотек возвращается часто, от строковых до работы с СУБД.

Рассмотрел проблему получше. Фиксить не будем потому как штука ну очень специфичная. `false` возвращается ради сокращения одного запроса к базе на каждую таблицу. Накладные расходы на фикс слишком высоки.
Sign up to leave a comment.

Articles