>> I would also argue that >>you should never, in any language, catch a NPE. The only time you >>should catch an NPE is if you are catching all exceptions, such as in >>a FastCGI daemon that will cleanly shutdown afterwards. > > If you're not allowed to catch it, why make it an exception? Benefits such as > unwinding finally blocks and destructors, and collecting backtraces, are > secondary effects, not really fundamental to exceptions.
This is not a new idea; a very quick search turned up the CERT Oracle Coding Standard for Java: "Programs must not catch java.lang.NullPointerException. A NullPointerException exception thrown at runtime indicates the existence of an underlying null pointer dereference that must be fixed in the application code[...] Handling the underlying null pointer dereference by catching the NullPointerException rather than fixing the underlying problem is inappropriate for several reasons." I'll let you read the standard for the justification. The point is that a few applications (and I mean a *very* few) need to be able to handle these kinds of failures; for example a web server shouldn't crash because the application throws a NullPointerException; rather the worker dies and the client will be sent a 500 error and the web server continues to run normally. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
