Stack backtrace on fatal error?

[Tim Tyler]

I'm getting fatal errors when executing code - and my error handler is
failing to trap them - so I get no stack backtrace :-(

The error I am getting is:

"Fatal error: Call to a member function fetchRow() on a non-object."

What are the available options here?

Am I supposed to check I have a real object whenever I perform
a method call - or run the risk of getting runtime errors which
give few clues about where the functions they are in are being
called from?

Is there some way of beefing up the error handler so that
"fatal errors" can be trapped - without using a customised
PHP parser at runtime?
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Andy Hassall]

On Fri, 17 Sep 2004 12:11:04 GMT, Tim Tyler <ti*@tt1lock.org> wrote:

I'm getting fatal errors when executing code - and my error handler is
failing to trap them - so I get no stack backtrace :-(

The error I am getting is:

"Fatal error: Call to a member function fetchRow() on a non-object."

Looks like a bug to me, this ought to go to the user defined error handler.
Have you checked bugs.php.net?

Attempts to get a property of a non-object goes through the user defined error
handler from a quick test, but not method calls.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Tim Tyler]

Andy Hassall <an**@andyh.co.uk> wrote or quoted:

On Fri, 17 Sep 2004 12:11:04 GMT, Tim Tyler <ti*@tt1lock.org> wrote:

I'm getting fatal errors when executing code - and my error handler is
failing to trap them - so I get no stack backtrace :-(

The error I am getting is:

"Fatal error: Call to a member function fetchRow() on a non-object."

Looks like a bug to me, this ought to go to the user defined error handler.
Have you checked bugs.php.net?

There they say that thay can't continue from fatal errors - because
the Zend engine has got its knickers in a twist by that stage -
but they /do/ also say:

``Fatal errors are fatal for a reason although there are some feature
change requests to separate out Zend fatals (which will never be
catchable) and PHP Fatal errors which maybe oneday we can make
catchable.''

- http://bugs.php.net/bug.php?id=9384

Another supposedly-fatal error: "Call to undefined function" :-(
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[R. Rajesh Jeba Anbiah]

Tim Tyler <ti*@tt1lock.org> wrote in message news:<I4********@bath.ac.uk>...
<snip>

Is there some way of beefing up the error handler so that
"fatal errors" can be trapped - without using a customised
PHP parser at runtime?

Custom error handler cannot handle the fatal errors; you need to do
the output buffering techniques. Look at the manual and user note
<http://in.php.net/set_error_handler#35622> When you use output
buffering, you cannot again use highlight_string(). I have written a
custom error handler to handle all these situations; as it is
proprietary, I cannot outsource it now.

HTH.

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com

[Tim Tyler]

R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:

Tim Tyler <ti*@tt1lock.org> wrote in message news:<I4********@bath.ac.uk>...

Is there some way of beefing up the error handler so that
"fatal errors" can be trapped - without using a customised
PHP parser at runtime?

Custom error handler cannot handle the fatal errors; you need to do
the output buffering techniques. Look at the manual and user note
<http://in.php.net/set_error_handler#35622> When you use output
buffering, you cannot again use highlight_string(). I have written a
custom error handler to handle all these situations; as it is
proprietary, I cannot outsource it now.

Interesting - thanks.

Unfortunately, calling debug_backtrace() within the fatal error handler
seems to produce one function call - to the fatal error handler itself -
so this approach does not seem effective at getting hold of backtrace
information for the fatal error - and getting hold of that information
was the main reason I was interested in trapping the error in the first
place.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Chris Hope]

Tim Tyler wrote:

"Fatal error: Call to a member function fetchRow() on a non-object."

It means that you've done eg $foo->fetchRow() but $foo is not actually an
object. Without seeing any of your code it is difficult to further diagnose
what your problem is.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

[Tim Tyler]

Chris Hope <bl*******@electrictoolbox.com> wrote or quoted:

Tim Tyler wrote:

"Fatal error: Call to a member function fetchRow() on a non-object."

It means that you've done eg $foo->fetchRow() but $foo is not actually an
object. Without seeing any of your code it is difficult to further diagnose
what your problem is.

I was not trying to fix that problem - it was an example.

I was trying to find a better way of fixing *all* such bugs -
by getting PHP to report where the problem code was called from.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Tim Tyler]

R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:

Tim Tyler <ti*@tt1lock.org> wrote in message news:<I4********@bath.ac.uk>...

Unfortunately, calling debug_backtrace() within the fatal error handler
seems to produce one function call - to the fatal error handler itself -
so this approach does not seem effective at getting hold of backtrace
information for the fatal error - and getting hold of that information
was the main reason I was interested in trapping the error in the first
place.

For me, it is working (4.3.4).

Hmm. I may try again someday.

It's a "dreadful hack" - but it /would/ be helpful if I could get it to work.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[R. Rajesh Jeba Anbiah]

Tim Tyler <ti*@tt1lock.org> wrote in message news:<I4********@bath.ac.uk>...

R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:

Unfortunately, calling debug_backtrace() within the fatal error handler
seems to produce one function call - to the fatal error handler itself -
so this approach does not seem effective at getting hold of backtrace
information for the fatal error - and getting hold of that information
was the main reason I was interested in trapping the error in the first
place.

For me, it is working (4.3.4).

Hmm. I may try again someday.

It's a "dreadful hack" - but it /would/ be helpful if I could get it to work.

There is a popular ErrorHandler class
<http://www.phpclasses.org/ErrorHandler>. Unfortunately, it didn't
attract me much, probably it may be useful to you. They trap so many
errors with additional JS.

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com