php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #51882 Call To Member Function on Non-Object Should Throw An Exception
Submitted: 2010-05-21 19:19 UTC Modified: 2014-10-07 22:11 UTC
Votes:8
Avg. Score:4.0 ± 1.4
Reproduced:6 of 7 (85.7%)
Same Version:1 (16.7%)
Same OS:0 (0.0%)
From: jacob at mediashaker dot com Assigned: thekid (profile)
Status: Closed Package: *General Issues
PHP Version: 5.2.13 OS: Centos 5.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jacob at mediashaker dot com
New email:
PHP Version: OS:

 

 [2010-05-21 19:19 UTC] jacob at mediashaker dot com
Description:
------------
Call to a member function on a non-object is one of the most common reasons a php script might crash.

Granted, there's often a whole chain of responsibility that falls apart for it to get to this point.

The problem with this fatal error is that it provides absolutely no debugging or traceback information when it happens. PHP blows up on fatal errors and all you're left with is a line number and no idea how it got there.

It would be awesome if it threw an exception with it's requisite traceback information.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-20 15:47 UTC] binarycleric at gmail dot com
I disagree with changing this from being a fatal error.  

Trying to call a method on an object that doesn't exist should always result in 
a fatal error because you are 
especially calling non-existent code. Trying to call a procedural function that 
doesn't exist should result in the 
same behavior.  I personally wouldn't want anything other than a fatal error to 
occur if I tried to call 
"some_import_func($herp, $derp);" and it didn't exist, because there is really 
no sane way to recover from that.  We 
have "function_exists" and "method_exists" for a reason.

If you are having constant problems like this with your code then that is 
usually a symptom of a larger problem in 
how your application is structured.  There are hacks and workarounds to get 
stacktrace information after a fatal 
error using things like "register_shutdown_function", but your code really 
shouldn't try to "recover" from a failure 
that catastrophic.

I don't mean for this comment to have an "internet toughguy" additude, I'm just 
trying to show you that your code 
may have more serious problems then you realize.  You already have a good number 
of tools in your toolbox, you just 
need to learn to use them better.
 [2011-07-26 21:10 UTC] jacob at mediashaker dot com
It's simply a general headache. I'm aware of the register_shutdown_function tricks but unless I've done it wrong, they don't provide a full, accurate stacktrace. In any case, this is exactly what this proposal is meant to avoid - created separate error-handling code paths for a common error that does not, from experience with other dynamic languages, need to be fatal.

In Python I get:
AttributeError: User instance has no attribute 'sayHello'

It's got a full traceback, it's catchable, it has a nicely subclassed error type. Fatal errors have none of this.

It's a larger issue in cases where you have more complex object object graphs, in cases where you have references to objects that pass hands frequently. etc. In an enterprise application with object compositions and complex class hierarchies, it's not unusual to have situations where you don't have the object you expect to have. Certainly, this is a bug, but bugs are the reality of software development and tracing them should be as easy as reasonably possible.

Unless you have xdebug installed for traceback information, you've got to find the line of code that initially caused the error and then do something like `var_dump(debug_backtrace())` to figure out the code path that led to the error. In a production system with hundreds of deployments, you often can't simply go around sprinkling debug statements in production code just to get debug information you could've had for free if the thing were an exception.

If my web app has a nice exception handling mechanism where uncaught errors are caught by a final, top-level exception handler, where I do things such as e-mail a sysadmin, or display the error in a pretty-formatted HTML page, these fatal errors slip through the cracks.

Unless this is a performance decision, or because the development team is limited by legacy support / backwards compatibility, the behavior simply sucks. From my POV, this does not need to be as difficult as PHP makes it. 

In general, PHP's errors are wonky. Half of them use trigger_error and error codes, others use exceptions, and finally, there's this big guy which is a fatal error.
 [2014-10-07 22:11 UTC] thekid@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: thekid
 [2014-10-07 22:11 UTC] thekid@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

https://wiki.php.net/rfc/catchable-call-to-member-of-non-object

Fixed in PHP 7.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 23:01:26 2024 UTC