@PetrovSerega30 янв 2013 в 10:04

Как я знакомился с Yii

3 мин

25K

PHP * Yii *

-4

Комментарии 48

@sergebezborodov 30 янв 2013 в 10:23

т.е. Вы подразумеваете что фреймворк должен сообщать Вам об ошибках в настройке вашего мускля?

@LighteR 30 янв 2013 в 10:38

Он должен был вывести ошибку, а не тихо промолчать.
Это типичный говнокод:

catch(Exception $e)
{
   return false; // !
}

@sergebezborodov 30 янв 2013 в 11:30

Вы всегда выводите ошибки в ваших функциях для автодополнения полей?

@LighteR 30 янв 2013 в 12:07

При чем здесь автодополнение полей?

@sergebezborodov 30 янв 2013 в 11:32

Потратив несколько часов на вставку var_dump-ов и отслеживания путей выполнения, я произвёл изучение следующих мест:

советую Вам потратить пол часа на изучение и настройку xdebug с Вашей IDE
вместо траты «часов с var_dump» хватит 3 минут пройтись по коду пошагово

@Voenniy 30 янв 2013 в 12:01

вы дебажили фреймворки?

@sergebezborodov 30 янв 2013 в 12:07

дебажил и не раз,
зачастую когда садишься за чтото новое, очень полезно пройтись пошагово от index.php хотя бы до экшена контроллера

@Voenniy 30 янв 2013 в 12:11

Мне ни разу за 3 минуты не удавалось пройти код пошагово :)

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

@Fesor 30 янв 2013 в 19:28

С Yii частенько приходилось вооружаться xDebug-ом, особенно на старых проектах.

@Voenniy 31 янв 2013 в 07:02

само собой, xdebug необходим.
Но, продебажить весь фремворк до какого-либо action, учитывая, что по пути может сработать несколько behavior — довольно утомительное занятие. Я ещё Zend пытался подебажить. Чуть не уснул, пока до action не добрался.
К счастью, всегда можно поставить брекпоинт :)

@PetrovSerega 30 янв 2013 в 12:03

Спасибо, xdebug обязательно настрою.

@RiderSx 30 янв 2013 в 12:10

Еще можно попробовать debug_backtrace :)

@PetrovSerega 30 янв 2013 в 13:08

Да, думаю это мне помогло бы.

@LighteR 30 янв 2013 в 12:06

Только зачем вы адресовали этот коммент мне?

@PetrovSerega 30 янв 2013 в 10:29

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

@Voenniy 30 янв 2013 в 10:35

Обычно SamDark отвечает в постах проYii.
Думаю, этот пост тоже не оставит без внимания

@Elkan 30 янв 2013 в 10:58

Пост тянет на название: «Я новичок в похапе, взял один из мощных фв и вот скажу какой он плохой, т.к. я сам не настроил mysql» :D автор не смешите...)

@PetrovSerega 30 янв 2013 в 11:07

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

@SamDark 30 янв 2013 в 12:07

Опа :) Подумаю, как бы лучше отображать ошибки в этом случае.

@PetrovSerega 30 янв 2013 в 12:09

Кстати, спасибо Вам за перевод документации. Интересно =)

@AYShestakov 30 янв 2013 в 20:47

Можно еще сказать, спасибо, и за разработку. Александр член core team Yii.

@PetrovSerega 31 янв 2013 в 09:47

Спасибо и за это)

@AYShestakov 30 янв 2013 в 20:48

Вот ответ не мальчика, но мужа.
Никаких препирательств — есть ошибка — исправим.

@edogs 30 янв 2013 в 12:37

Вообще «Can't create/write to file '/root/tmp/» должна была валиться в лог ошибок php при выполнении запроса в mysql, не искали там? А дальше подключившись к обработчику ошибок mysql можно было бы и увидеть откуда у нее ноги растут (debug_back_trace хотя бы).

@PetrovSerega 30 янв 2013 в 13:05

Посмотрел только сейчас =(
Здесь "/var/log/apache2/error_log" не нашёл записей с похожими формулировками.

@edogs 30 янв 2013 в 16:25

Отсюда 2 вопроса — логи ошибок php у Вас пишутся? И если да, то точно в /var/log/apache2/error_log?
Просто если у Вас временная директория не настроена в mysql, то возможно и с записью ошибок какой-то косяк.

@PetrovSerega 30 янв 2013 в 17:04

Логи туда пишутся. Например есть запись от вчерашнего числа:
«PHP Warning: htmlspecialchars(): charset `utf8' not supported»
Но записи нет. Возможно и косяк где-то присутствует.
В любом случае, спасибо за наводку. Изучу вопрос подробнее.

@AYShestakov 30 янв 2013 в 20:49

ну в debug режиме yii выводит отличный trace — только иногда обрезает код на самом интересном. Но это уже мелочи.

@alphard 30 янв 2013 в 21:42

К чему это здесь? Теперь на пост на хабре заменяет issue?

Сунулись бы сюда для начала.

@romkatsu 30 янв 2013 в 22:05

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

@Xergin 30 янв 2013 в 22:23

Еще к слову о говнокоде:

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

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

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

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

@Fesor 30 янв 2013 в 22:41

false возвращается только в случае если ридер уже не может что-то вернуть. Если ридер вернет вам ноль, то первый вариант отработает, а второй нет.

@Xergin 30 янв 2013 в 22:55

А теперь смотри сюда, дружок:
CDbDataReader#read-detail

И на заметку тебе:
Если функция может вернуть как 0, так и false, то значит с ней что-то не так.

@artem_kovardin 30 янв 2013 в 23:42

Всегда знал, что со strpos что то не так! Вот чувствовал, просто! Спасибо, дружок!

@Xergin 30 янв 2013 в 23:56

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

Спасибо, дружок!

@sectus 31 янв 2013 в 05:31

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

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

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

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

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

@balloon 31 янв 2013 в 05:45

В таком случае должен быть еще метод вроде hasPoint():bool, который проверяет находится ли точка в заданом отрезке, а сам метод getPoint() должен создавать исключение при попытке взять точку вне отрезка.

@sectus 31 янв 2013 в 06:19

ммм… Кстати, да. Таким подходом я и сам пользуюсь. Но не всегда.

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

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

Вместо

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

получим что-то типа:

while($dataReader->hasData()){
    $row=$dataReader->read();
...
}

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

Хотя можно было бы сделать и так

while($dataReader->hasData() && $row=$dataReader->read();)
...

И так тоже многословнее.

@Xergin 31 янв 2013 в 08:47

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

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

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

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

@sectus 31 янв 2013 в 09:52

Если я хочу найти вхождение подстроки в строку(в 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 в аналогичных ситуациях.

@Xergin 31 янв 2013 в 10:14

Взять хотя бы erlang, которые в некоторых случаях возвращает false в аналогичных ситуациях.

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

@sectus 31 янв 2013 в 11:51

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

keysearch(Key, N, TupleList) -> {value, Tuple} | false

@Xergin 31 янв 2013 в 12:02

и тем не менее это очень похоже именно на то о чём идёт речь.

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

В примере же возвращается вполне конкретный tuple.

@sectus 31 янв 2013 в 13:01

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

@VolCh 31 янв 2013 в 11:14

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

@Xergin 31 янв 2013 в 11:56

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

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

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

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

@VolCh 31 янв 2013 в 12:26

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

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

@SamDark 13 фев 2013 в 19:09

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий