php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #26789 NullPointerException desired
Submitted: 2004-01-04 18:23 UTC Modified: 2012-10-20 09:52 UTC
Votes:23
Avg. Score:4.4 ± 1.1
Reproduced:20 of 20 (100.0%)
Same Version:9 (45.0%)
Same OS:9 (45.0%)
From: davidc at blesys dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: 5.0.0b3 (beta3) OS: (doesn't apply)
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: davidc at blesys dot com
New email:
PHP Version: OS:

 

 [2004-01-04 18:23 UTC] davidc at blesys dot com
Description:
------------
I desire a NullPointerException to be thrown, like in Java.
Currently, a fatal error triggers, stopping my entire application.

Many times an object may be null, but the application can continue. In addition, if an exception were thrown, I could trace it to see why the exception occured.



Reproduce code:
---------------
$j=null;
$j->someMethod();

Expected result:
----------------
Fatal error: Call to a member function someMethod() on a non-object in file.php on line 2


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-05 03:00 UTC] derick@php.net
If you want to have "NULL" objects, test if an object is NULL before you call methods on it. There is no chance this will be implemented. 
 [2012-03-13 22:22 UTC] me at joshsera dot com
The point of an NPE is so you can enclose code in a try/catch block instead of 
wrapping every statement in an if that tests for null. It makes for more readable 
code.
 [2012-10-20 04:12 UTC] 3leven11 at gmail dot com
I find the comment by derick@php.net to be very unhelpful.

Testing an object for null every time you use it while being a solution, is a 
very primitive way of ensuring your application does not crash in an ungraceful 
manner. Exception handling, is a much more efficient way of ensuring your 
application can continue running when abnormal events occur.

While I agree that it is up to the developer to handle if an object is null, I 
do see a case where checking for null is an unnecessary performance hit on any 
application. And could be avioded by the implementation of a 
NullPointerException in PHP. Handling errors in code is up to the developers, 
but they can only handle them the best way they know how, with the tools 
provided to them. 

Take the example of an object that you rarely expect to be null, like a PDO 
object. I expect my database to be available 99.9% of the time, are you really 
implying that it is better practice to test for null every I use this object 
rather than enclose my use of a PDO object within a try catch block, handling 
any exception that may arise?

example code:

// base class

namespace lib\translator;
use lib\database as db;

class EntityTranslator {
    protected $dbConn;
    
    public function __construct() {
        try {
            $this->dbConn = db\Database::getInstance();
        }
        catch(\PDOException $e) {
            // do some error logging here
        }
    }
}


// subclass

namespace lib\translator;
use lib\entity as entity;

class OrderRequestTranslator extends EntityTranslator {
    
    public function __construct() {
        parent::__construct();
    }
    
    public function createOrderRequest() {
        $request = new entity\Request();
        try {
            $stmt = $this->dbConn->prepare("CALL createRequest()");
            $stmt->execute();

            $rowCount = $stmt->rowCount();
            if ($rowCount == 1) {
                $row = $stmt->fetch(\PDO::FETCH_ASSOC);
		
		// do stuff with the data here
            }
            return $request;
        }
        catch (\PDOException $pdoe) {
	    // do error logging here
        }
	catch (\Exception $ex) {
	    // do error logging here
        }
    }
}


So in the above example, if there is an exception while connecting to the 
database, which as I pointed out I expect to very rare, and it may actually 
never happen, that before issuing the call to $this->dbConn I should check if 
$this->dbConn is null?

This is the perfect case for where my catch(\Exception $ex) {} block would be 
perfect. I really never expect to be in that code, from my point of view, and 
correct me if I am wrong, I have not coded my application in an incorrect way, 
except for the fact that PHP has no NullPointerException.
 [2012-10-20 08:37 UTC] nikic@php.net
@3leven11: I have a hard time understanding your particular situation. I mean, if you can't connect to the database, then you should throw an exception *at that point* (PDO actually does it for you, but you choose to silence the exception).

If you need this to check for such error conditions then I would highly recommend you to just throw an exception as the error occurs rather than passing NULLs around everywhere. That's basically the "error code" way of handling errors (in your case even without the code) and it indeed involves checking every single call. That's why people mostly prefer throwing exceptions.
 [2012-10-20 09:52 UTC] pajoye@php.net
-Package: Feature/Change Request +Package: *General Issues
 [2012-10-20 09:52 UTC] pajoye@php.net
In addition to Niki's comment, there is no such thing like pointer in PHP.
 [2012-10-20 10:21 UTC] 3leven11 at gmail dot com
@nikic, I completely understand what you are saying, and I have indeed 
altered my code to pass the exception up the chain to the callers of the sub class 
constructors. I still think a NullPointerException over a Fatal Error would be 
nice, but that is just my Java developer way of thinking.

I appreciate you taking the time to respond.
 [2012-10-20 11:47 UTC] nikic@php.net
@3leven11: This will definitely not be a NullPointerException (because PHP doesn't have pointers and because PHP does not throw exceptions from core), but it could be changed to an E_RECOVERABLE error. You wouldn't be able to conveniently catch it, but you could still handle it (e.g. display an error page rather than just a WSOD). It think @ircmaxell wanted to make it a RECOVERABLE, but I don't know what the state on that currently is.
 [2012-10-21 00:31 UTC] 3leven11 at gmail dot com
@nikic, If that were to happen I think it would be great. I found this request 
which is exactly what you have mentioned https://bugs.php.net/bug.php?id=46601 and 
at the bottom, there is a comment providing a workaround. Thanks again.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 21:01:27 2024 UTC