• Get in touch
  • img
PHP Fatal errors into exceptions natively

In my last blog post I was writing about fatal error problems when undefined methods do occur. I decided to wait with implementation to see what will other developers say and I was surpised a bit with how much people disagreed with the idea. Tthank you all for feedback here, on twitter and reddit since this got me thinking a little bit more.

If you concept your OO classes on public properties vs. getters/setters your PHP code behaves totally different. Lets say you want to load user 79 and print out a welcome message:

Using getter method that is not implemented will get you fatal error saying how undefined method is called and request will stop.

 
// Instantiate class.
$objUser = new User();
// Load user.
$objUser->load( 79 );
// Print out username
echo 'Hello ' . $objUser->getName() . '!';

On the other hand if you would use public property all you would get is a notice saying how this property does not exist and rest of request would be completed.

 
// Instantiate class.
$objUser = new User();
// Load user.
$objUser->load( 79 );
// Print out username
echo 'Hello ' . $objUser->name . '!';

I know that this is due to dynamic typing behavior of PHP and no I am not suggesting raising a notice if undefined method gets called but since 5.1.0 there is a BadMethodCallException class which would be perfect for this situations. Since I’m not the first one coming with this idea I found a few reports on PHP bug tracker that were closed due to this not being a bug. Since I don’t want to spam bug tracker with a copy of already reported and closed issues I was wondering should one of next PHP versions support this as a feature?

If you like the idea please leave a small comment here and if there would be enough interest we could suggest it at PHP RFC Wiki . There are already few similar RFCs but they are not regulating fatal errors ( example ).

About the author
msvrtan

4 Comments

Atachi

2012-08-29 07:44:21 Reply

While PHP needs better error handling, making everything an exception should not be the solution.

Exceptions should only be thrown by run time errors, not compile time errors.
A missing method on a class is compile time – except when using dynamic classes (there reflection can perhaps throw an exception).

THe problem with this perception is, that PHP is too dynamic in that regard. It shouldn’t actually give any existing output if there is a compile error somewhere as it leads to this idea that “I want to catch fatal errors and continue from there”.
If you need to actually continue after a fatal error, you should rework your architecture to prevent it from even happening.

At least that is my opinion – and that of several other programming languages.

mario

2012-08-30 14:18:22 Reply

I’m confused about the use case here. If you call an undeclared method, you get a fatal error.

Why would you want en exception here? Exceptions are for errors that may occur at runtime. Undeclared methods are something that occurs and should be effing fixed at the development stage. If you can’t get it fixed until deployment, I’m not sure an assortment of exceptions raises the code quality measurably.

Patrick

2013-06-04 20:09:48 Reply

While I agree that missing methods should be addressed in the development stage, there are times when it would be useful to catch the fatal error.

Here is an example: Our site’s production configuration does not display the Fatal Error. If an error occurs, an error page is displayed for a period of time and then the user is redirected to the Front Page of the Site. However if the Fatal Error occurs on the front page, then the browser’s default error page shows, (except Firefox which only shows a white page).

Now the Fatal Error will be show in the development environment, but what happens if a new deployment to the Production Servers happens to fail to deploy a file that has a new function in it? On our production site we have to isolate all the changes in the controller file that is not working and then isolate which support file failed to deploy.

If on the other hand we were able to catch the Fatal Error and write it to a log file, then looking at the log file would quickly identify what failed to be deployed.

David

2013-07-26 09:11:30 Reply

I’m currently writing a public API which immediately opens up this issue of undeclared methods: user simply makes a bad api call. So I have to guard against it by running method_exists and/or is_callable for every request, %99.9999 of which I expect to be correct. So that is my use case for being able to turn fatal errors into catchable exceptions which can be handled gracefully. I’m sure there are many others.

Leave a Comment