Форум PHP

тему когда-то я уже поднимал.. но тогда четкого решения задачи так и не нашел. На днях вернулся к теме (это было часть системы сбора статистики). Вобщем придумал я как легко без кучи кода отследить и записать в лог возникшые ошибки, как в пхп коде так и при SQL запросах. я попозже выложу свои результаты но сейчас такой вопрос: есть ли в пхп какая-либо функция которая бы возвращала номер строки в коде на которой она находиться? если нет такой, то возможно ли такую функцию реализовать?

вот архивчик, там три файла

count_ini.php - ини файл
php-mysql-errors.php - файл с функцией
count_comm.php - этот файл надо инклюдить в самом начале вашего файла.

далее:
необходимо создать директорию в которой будут храниться файлы
в ини файле:

stat_dir - полный путь к директории (например d:/server/www/stat/) обязательно на конце /
show_err - 1 отображает ошибки, 0 тупо записывает и никому об этом не говорит
errors - типы ошибок которые необходимо регестрировать. Задаеться числом (1, 2,4,8,16, ..., 1024) разделяеться одним(!!!) пробелом
остальное не трогать, оставить как есть.

Вообще для этого предназначены исключения, но они работают только начиная с PHP 5.

исключения - это что? /* пишу понимая что что-то в этой жизни я безвозвратно упустил */. Но к вопросу об отлове mySQL ошибки.. после каждой операции с БД должна будет стоять функция (так сказать паучок) которая будет отлавливать ошибки и выдавать пользовательскую ошибку пхп, которую, в свою очередь, обработать гораздо проще... придумал пока ехал в автобусе поэтому пока не проверил, скажите в этом случае ведь будет фиксироваться и имя файла и строчка?

а по поводу функции "паука" может есть более изящный способ? по мускулу я нашел только две функции отработки ошибок: mysql_errno() и mysql_error(), но они применимы только к последнему запросу к БД поэтому приходиться использовать паука после каждого обращения к базе. Жаль что нельзя как с пхп ошибками.... или можно? (имею ввиду использование функции set_error_handler(...))

добавлено:
начал щас тестить на хостинге, и опять козява с SAFE MODE вылезла!!!! вот что пишет зараза:

Warning: parse_ini_file(): SAFE MODE Restriction in effect. The script whose uid is 32310 is not allowed to access /home/wesmarru/public_html owned by uid 0 in /public_html/stat.data/count_comm.php on line 3

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

с SAFE_MODE разобрался: дело в том что в файле count_comm.php адрес к ини файлу прописан относительно count_comm, т.е. parse_ini_file ("count_ini.php"), на локалке такое прокатывало, на хостинге нет, пришлось путь к ини файлу прописывать относительно файла к которому непосредственно обращаемся, т.е. пришлось написать parse_ini_file ("../stat.data/count_ini.php"), придется это как-то исправлять...

Пример с исключениями можно найти в теме по ссылке http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=641 и нашей книге "Самоучитель PHP 5" http://www.softtime.ru/php5/?id_article=6.
По поводу обработки ошибок после каждого запроса - ничего не поделаешь, так как Web-сервер и MySQL-сервер - это две разные программы с разным адресным пространством. Придётся обрабатывать каждую ошибку. В MySQL 5.0 появились обработчики ошибок в хранимых процедурах, но MySQL 5.0 пока находится в стадии бета-тестирования.

слушайте..... начал тестить обработку статистики.. и тут неприятная вещь вылезает... т.к. данные о посещениях храняться в xml файлах (причем для каждого дня отдельный файл) то обработка всей это кучи занимает (у меня на локалке) 0,2 сек, но веть это еще пустая база.. а если будт по 200 посещенеий в день... боюсь щет может перейти на секунды... так что же делать... можжно так оставить или перейти на упрощенную структуру файлов? (mySQL не предлагать т.к. все это удобней организовать на файлах... особенно на xml)

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

вроде выход нашел, сделал нечто вроде буферизации, при загрузке статистики (первая страница загружает обобщенную статистику за месяц ) все эти данные записываються во временный файл с упрпощенной и достаточно удобной структурой, в итоге: у меня уже была собрана статистика за несколько последних месяцев, кол-во просмотров - около 1000 за месяц, без буфера время обработки страницы (на моем компе) в среднем около 0,5 с, с буфером удалось уменьшить время почти в 10 раз... на хосте это время скорее всего будет еще меньше...

ну что, прокатит?

Покатит... сервер и локальная машина - это две большие разницы - у них и память под сервер разная выделяется и железо отличается здорово.