Blog |

E_ERRORs in PHP: What You Need to Know

E_ERRORs in PHP: What You Need to Know
Table of Contents

What is E_ERROR?

PHP’s E_ERROR typically indicates a major issue with PHP. Normally, PHP may be able to recover from a lesser error and the PHP application could continue to run. However, with E_ERROR, PHP will usually outright fail and stop working entirely.

 

What causes E_ERROR?

Several factors can cause an E_ERROR to occur. The examples below are generalized to get the point across regardless of which version of PHP you are using.

 

Wrong Type

You may, for example, have a function definition which is called or used incorrectly.

function my_function (a_value: String) {
    echo a_value;
}

my_function(123);

In the example above, you would receive an E_ERROR related to the fact that you are using an integer when a string is expected.

 

Parsing Errors

You may also have parsing errors that cause E_ERROR to show up such as a missing semicolon or an unexpected character. Here is an example:

function my_function (a_value: String) {
    echo a_value
})

my_function(123);

Note how there’s a missing semicolon after “echo a_value” and there’s an extra bracket at the end of the curly function bracket. Both (or just one of these) would cause an error.

 

Calling an Undefined Function

You may also be calling an undefined function. For example, if you simply call “my_function” without ever first declaring it, you will get this error. Or you may have a dependency chain failure wherein your function definition is run later on in the code, after you’ve called it, although this tends to be rare.

 

Insufficient Memory

This error can also be caused by memory issues. Primarily, if PHP is running out of memory while attempting to process something (or even just simply idling in some cases) the application will crash with E_ERROR as its output.

 

How to Solve PHP’s E_ERROR

One of your first lines of defense is having a good PHP linter to do some of the heavy lifting for you. Linters like PHPLint are great. You may also benefit from a good IDE like Visual Studio Code which has plugins for linters that will automatically show you syntax or other issues as you code.

If you are confident your syntax is good then you will want to consider whether your PHP application is using 3rd party packages that might be causing some trouble. For example, if you’re using Composer, perhaps you’ve installed a 3rd party library and are not using it correctly. Sometimes, depending on the configuration of your linter, even these kinds of issues can be caught but it is worth checking.

Usually E_ERROR comes with enough messaging to figure out where it is occurring and resolve it directly. Most of the time, this error is caused by simple things (like typos) that are easily fixed.

In the case of memory issues, however, the resolution may be far more complicated. You can ensure your PHP code is not causing memory issues by using tools like xdebug to step through your code and look at what is occurring. Make sure you are not running endless for/while loops, building massive arrays or holding large objects/data in memory. If you feel pretty confident you are not writing code that could be eating up memory then other factors may be at play. Could a 3rd party library be causing a spike in memory usage? If you’re on a shared hosting provider then maybe your provider has limited the amount of available memory you can use.

When in doubt, remove the offending code until you are back to a stable place. If, for example, are limited to how much memory you can use? Shared hosting providers can sometimes give you very low memory boundaries. Your PHP configuration may also be limiting how much memory is available to the application. It would be wise to double check your PHP’s INI or CONF files, as appropriate to your operating system and environment, to ensure enough memory is allocated. It may also be prudent to look at what else you are running in parallel to your PHP application. For example, perhaps you have a 50MB maximum availability of memory on your server and a MySQL server is eating up 49MB. Your PHP application may be completely valid, syntactically correct and very efficient. However, it may be blocked by the MySQL server eating up the available memory.

If you believe some kind of for loop is the cause of a memory issue but are unsure, simply comment it out and see if the error appears again. If you believe a 3rd party library is the cause, comment out uses of it (or remove it entirely) and see what happens. This may be easier said than done but you might find an easy answer by exploring this option.

Another way to work past this is to implement a “register_shutdown_function” (requires PHP 5.2+) which will catch E_ERROR conditions and handle them as gracefully as you like. This may be a way for you to allow the error to continue to occur without having the entire application grind to a halt. This is *not recommended* as you may be causing other damage but it is an option.

Never ignore E_ERROR issues and messages. They are critical flaws in your PHP applications that must be addressed as soon as possible.

 

Track, Analyze and Manage Errors With Rollbar

Managing errors and exceptions in your PHP code is challenging. It can make deploying production code an unnerving experience. Being able to track, analyze, and manage errors in real-time can help you to proceed with more confidence. Rollbar automates error monitoring and triaging, making fixing PHP errors easier than ever. Sign Up Today!

Related Posts

See all posts

"Rollbar allows us to go from alerting to impact analysis and resolution in a matter of minutes. Without it we would be flying blind."

Start continuously improving your code today.

Get Started Shape