реальный номер строки с ошибкой

[benadin]

реальный номер строки с ошибкой

Для работы с базой данных используется специальный класс. Когда в середине основного класса происходит вызов $foo->fetchObj() или $foo->query(); и запрос содержит ошибку, то php parser сообщает о номере строки с ошибкой - являющемся номером строки метода sql-ного класса.
Как можно определить строку основного класса (или скрипта), в к-ой этот метод вызывается?

 

[[VS]]

Re: реальный номер строки с ошибкой

никак
передавай параметром

 

[benadin]

Re: Re: реальный номер строки с ошибкой

Автор оригинала: [VS]
никак
передавай параметром

А разве можно каким-либо способом передать в функцию (метод) номер строки, из к-ой она вызывается?

Неужели все так мучаются, и нет никакого решения? Отлаживать временами ведь просто мучительно

 

[Yurik]

А разве можно каким-либо способом передать в функцию (метод) номер строки, из к-ой она вызывается

псевдо-константа __LINE__

Foo (arg1, arg2, __LINE__, __FILE__);
__LINE__ will contain the line, __FILE__ will contain the file, where the function Foo() was called.

 

[[VS]]

Автор оригинала: Yurik
псевдо-константа __LINE__

Foo (arg1, arg2, __LINE__, __FILE__);
__LINE__ will contain the line, __FILE__ will contain the file, where the function Foo() was called.

Yurik: человек другое спрашивал.

 

[[VS]]

Re: Re: Re: реальный номер строки с ошибкой

Автор оригинала: benadin
А разве можно каким-либо способом передать в функцию (метод) номер строки, из к-ой она вызывается?

Неужели все так мучаются, и нет никакого решения? Отлаживать временами ведь просто мучительно

1 - параметром передавай, какие проблемы.
2 - никто не мучается, используй нормальный php debuger, там будут видны и номера строк и call stack и значения всех переменных.

 

[Crazy]

debug_backtrace

 

[benadin]

Как раз Yurik дело говорит!
if (!$res) echo $line; - примерно так, это то что надо.

debug_backtrace - только в php >= 4.3.0
Не спешим повсеместно использовать

"1 - параметром передавай, какие проблемы" - с __LINE__ - никаких

"2 - никто не мучается, используй нормальный php debuger" - что порекоммендуешь?

 

[Ustas]

Те, кто когда-нибудь писал на нормальных объектно-ориентированных языках или хотя бы читал книжки по ООП, наверняка слышали об исключениях (или исключительных ситуациях).
При возникновении исключения (причем это может быть синтаксичкская ошибка в только что подключенном модуле или исключение сгенерированное программистом при получении от пользователя некорректных данных) интерпретатор прекращает выполнение программы и переходит к ближайшему блоку обработки. Если такого блока на данном уровне нет или в этом блоке это искючение не обрабатывается, то оно проходит на уровень выше, т.е. возвращается туда, откуда был произведен вызов функции, в которой произошел сбой. И такой каскадный "проброс" исключения может производиться до самого верха. Это удобно, т.к. на низших уровнях абстракции трудно судить о том, какая ошибка возникла: фатальная или программа может ситуацию как-то исправить. Правильная программа вообще не должна завершаться аварийно.

Но! В php систему каскадной обработки исключений обещают только к 5-й версии. на работе я пишу на php, но для души - на python'е...

 

[tony2001]

try, catch & throw уже есть в версии РНР с CVS.

 

[Ustas]

2tony2001:
Я в курсе. Только в устойчивой версии этого еще нет.
Впрочем, здесь проблема не в том, есть или нет. А в идеологии языка. Php это не серьезно... imho.

На работающий под нагрузкой сервер ставить экспериметальную версию не желательно.. А задачи решать надо..

 

[tony2001]

>Я в курсе. Только в устойчивой версии этого еще нет.
я тоже в курсе =) ждите.

>Впрочем, здесь проблема не в том, есть или нет. А в идеологии языка. Php это не серьезно... imho.
гм.
интересно было бы услышать почему.
причем, желательно в виде "вот этого - реально не хватает", а не "там это есть - а тут нет".
можно?

>На работающий под нагрузкой сервер ставить экспериметальну версию не хочется.
и правильно.
для этого есть тестовые серваки и рабочие машины.

 

[Ustas]

2tony2001:
> интересно было бы услышать почему.
> причем, желательно в виде "вот этого - реально не хватает", а не "там это есть - а тут нет".
> можно?
Можно. О несоответсвии php идеологии ООП, я думаю, можно не говорить. Язык изначально позиционировался как альтернатива perl, который в свою очередь произошел ои unix'овых shell-скриптов, а в них, в свою очередь, ООП просто не было за ненадобностью.
То "ООП", которое есть в php это скорее имитация. Доказывать это бессмысленно, т.к. вещь, imho, очевидная.
Простой пример... С твоего позволения я все-таки обращусь к первоисточнику: smalltalk'у, с которого-то и пошло ООП. С++ - это гибрид, поэтому я его не трогаю. Так вот в Smalltalk'е любая строка или число - это объект, у которого есть свои методы.
Чтобы реализовать такую же возможность в php, придется здорово перелопатить код php и хорошо помучиться с обратной совместимостью.
Можно продолжать...

Я не говорю, что php типа sux. Просто он не соответствует моим потребностям, и по различным причинам это неизлечимо без коренного пересмотра концепций языка...

 

[[VS]]

Автор оригинала: Ustas
Простой пример... С твоего позволения я все-таки обращусь к первоисточнику: smalltalk'у, с которого-то и пошло ООП. С++ - это гибрид, поэтому я его не трогаю. Так вот в Smalltalk'е любая строка или число - это объект, у которого есть свои методы.

Smalltalk - хороший язык для идеологии, но писать на нем программы требующие реальное кол-во памяти и выполняющиеся не слишком медленно - практически не реально.
А хорошо или плохо то что любое число - обьект, это отдельный разговор. В Java сначала так и сделали, потом поняли что нужны как минимум native числа, иначе тормозить все будет и памяти в несколько раз больше чем нужно кушать.

 

[.des.]

Простой пример... С твоего позволения я все-таки обращусь к первоисточнику: smalltalk'у, с которого-то и пошло ООП. С++ - это гибрид, поэтому я его не трогаю. Так вот в Smalltalk'е любая строка или число - это объект, у которого есть свои методы.

Простите, но это ответ на вопрос -

причем, желательно в виде "вот этого - реально не хватает", а не "там это есть - а тут нет".

Это скорее указание чего нет в пхп, но никак не ответ, на то чем это реально мешает вам? а тони2001 просил о другом.

Ну зачем пытаться везде прикрутить ооп? Именно прикрутить...
потому что для задач, решаемых при помощи PHP, хватает ООП в том виде, в котором он сейчас в нем существует.

Да, не скрою, блок try catch это то, чего допустим и я жду с нетерпением, но, простите, приводить объектную модель пхп к объектной модели smalltalk это просто глупо.

не говорю, что php типа sux. Просто он не соответствует моим потребностям, и по различным причинам это неизлечимо без коренного пересмотра концепций языка...

Именно это вы и говорите. Но поймите если у вас возникают такие потребности - именно такие без чего вашим проектам не обойтись, вы выбрали не тот язык и ява вас спасет.
Хотя и ее модель далека от smalltalka.

 

[ErrN0]

чего реально не хватает так это namespace'ов

 

[[VS]]

по поводу обращений к первоисточнику - SmallTalk,
если говорим о теории - пожалуйста, а если о практике
- тут есть кто-то, кто писал на SmallTalk более серьезные программы, чем на PHP?

 

[Crazy]

Автор оригинала: [VS]
тут есть кто-то, кто писал на SmallTalk более серьезные программы, чем на PHP?

Писал бы, если бы было, где их хостить.

ЗДЕСЬ ты таких врад ли найдешь. Но, в принципе, я лично знаю человека, давно и всерьез пишущего на smalltalk. За те 6 лет, что я с ним знаком, его маньячество не убавляется.

 

[Crazy]

Автор оригинала: Ustas
2tony2001:
Чтобы реализовать такую же возможность в php, придется здорово перелопатить код php и хорошо помучиться с обратной совместимостью.
Можно продолжать...

Вносить изменения в потроха PHP придется. Но, IMHO, вовсе не такие катастрофические. С совместимостью же я никаких проблем вообще не вижу. Нельзя ли подронее об этом?

 

[Crazy]

Автор оригинала: [VS]
В Java сначала так и сделали, потом поняли что нужны как минимум native числа

А нельзя ли подробнее об этом малоизвестном моменте истории языка? Я про "в начала так и сделали".