Php error messages format

The Complete Guide to PHP Error Reporting in 2021

PHP has been around for quite a while and has developed its own quirks and characteristics. It has also developed its own flavor of error reporting, which is fairly straightforward. In this post, we’ll show you how easy it is to add error monitoring for PHP.

What is a PHP error?

A PHP error is a data structure that represents something that went wrong in your application. PHP has some specific ways you can invoke errors. One easy way to simulate an error is with the die() function:

die("something bad happened!");

This will end the PHP program and report an error. When a program is ended, this is what we would call a fatal error. You’ll see later that we can control how exactly the error is handled, in case we need to invoke some cleanup logic or divert where the error reports. You can also simulate this with the trigger_error() function:

php  trigger_error("something happened"); //error level is E_USER_NOTICE  //You can control error level  trigger_error("something bad happened", E_USER_ERROR); ?> 

This will trigger a nonfatal notice in the system by default. You can override the error level if you need a more severe error.

There are actually two forms of errors in PHP: standard run-of-the-mill errors, and exceptions.

Exceptions were introduced in PHP 5. They give you easier semantics like try , throw , and catch . It’s easy to throw an exception. This follows along with the great success statically typed languages, like C# and Java, have had with them.

throw new Exception("Yo, something exceptional happened); 

Catching and throwing exceptions tend to be more streamlined than the more traditional PHP error handling. You can also have more localized error handling, as opposed to only handling errors globally via set_error_handler(). You can surround specific logic with try/catch blocks that only care about specific exceptions:

php try   doSystemLogic(); > catch (SystemException $e)   echo 'Caught system exception '; >  try   doUserLogic(); > catch (Exception $e)   echo 'Caught misc exception '; > ?> 

What are the different types of errors in PHP?

A PHP error isn’t a single thing, but comes in 4 different types:

Parse or Syntax Errors

The first category of errors in PHP are parse errors, also called syntax errors. They simply mean there are one or more incorrect symbols in your script. Maybe you’ve missed a semi-colon or misplaced a bracket. Take a look at the following example:

php $age = 25;  if ($age >= 18   echo 'Of Age'; > else   echo 'Minor'; > ?> 

By running the script above, I get the following error:

Parse error: syntax error, unexpected ' in path> on line 4

With the help of the error message, it’s easy to see the if statement lacks a closing parenthesis. Let’s fix that:

php  $age = 25;   if ($age >= 18)   echo 'Of Age';  > else   echo 'Minor';  > ?> 

Fatal Errors

Fatal errors, as their name suggests, are the ones who are capable of killing—or crashing—the application. In other words, fatal errors are critical errors, meaning something catastrophic happened and the application can’t go on.

Often, the reason for fatal errors is an undefined class, function, or another artifact. If a script tries to use a function that doesn’t exist, PHP doesn’t know what to do and the script must be stopped.

Consider the following script:

php  function add($a, $b)    return $a + $b;  >   echo '2 + 2 is ' . sum(2, 2); ?> 

As you can see, the script defines a function called add and then tries to call it by the wrong name. This situation results in a fatal error:

Fatal error: Uncaught Error: Call to undefined function sum() in F:\xampp\htdocs\test.php:7 Stack trace: #0 thrown in on line 7 

All it takes to solve the error is changing the function call to the correct name, add:

Warning Errors

Warning errors are errors that don’t result in script termination. Similar to what happens in other languages, a warning in PHP usually represents something that’s not yet a full-blown problem—or at least not a critical one—but it might become a serious issue in the future, so you’d better keep an eye on it.

Take a look at the following code:

php  $components = parse_url();  var_dump($components); ?> 

After running the code above, we get the following warning:

Warning: parse_url() expects at least 1 parameter, 0 given in path> on line 2

What’s causing the warning is the fact we haven’t supplied a parameter to the parse_url function. Let’s fix that:

php  $components = parse_url('https://example.com');  var_dump($components); ?> 

array(2) < ["scheme"]=> string(5) "https" ["host"]=> string(11) "example.com" >

Notice Errors

Notice errors are similar to warnings in that they also don’t halt script execution. You should also think of notice errors as PHP giving you a heads up to something that might become a problem in the future. However, notices are usually considered less critical or less intense than warnings.

Consider the following piece of code, which is an altered version of the script used in the previous sections:

php  $numbers = "1,2,5,6";  $parts = explode(",", $integers);   echo 'The first number is ' . $parts[0]; ?> 

As you can see, the script defines the variable $numbers, and then tries to pass a variable called $integers to the explode function.

Undefined variables are indeed one of the leading causes of notices in PHP. To make the error go away, suffice to change the $integers variable to $numbers.

How to enable error reporting in PHP

Enabling error reporting in PHP is dead easy. You simply call a function in your script:

php error_reporting(E_ALL);  //You can also report all errors by using -1  error_reporting(-1);  //If you are feeling old school  ini_set('error_reporting', E_ALL); ?> 

This says “please report errors of all levels.” We’ll cover what levels are later, but consider it a category of error. So it’s essentially saying “report all categories of errors.” You can turn off error reporting by setting 0:

The method parameter in error_reporting() is actually a bitmask. You can specify different combinations of error levels in it using this mask, as you can see:

php error_reporting(E_ERROR | E_WARNING | E_PARSE); ?> 

This says “report fatal errors, warnings, and parser errors.” You can simply delimit by “|” to add more errors. Sometimes you may want more advanced error reporting settings. You can leverage bitmask operators to report on a variety of criteria:

php // Report all errors except E_NOTICE  error_reporting(E_ALL & ~E_NOTICE); ?> 

As you can see, you have quite a bit of flexibility in determining what errors to report. That does beg the question: what types of errors and exceptions are there to report on?

How many error levels are available in PHP?

There are a whopping 16 error levels in PHP 5. These errors represent the category and sometimes severity of an error in PHP. There are a lot, but the numerous categories let you easily identify where to debug an error from its level alone. So, if you wanted to do something specific only for user errors, like input validation, you can define a condition handler for anything starting with E_USER . If you wanted to ensure you shut down a resource, you can do that by clueing into errors ending with _ERROR .

Errors in PHP are for the most part categorized by their severity (error warning, notice) and source (user, compiler, runtime).

I want to hone in on a few popular ones here.

First up, we have the general errors:

• E_ERROR (Value 1): This is the quintessential fatal error. If you see this bad boy, your app is done for. Restart and try again.
• E_WARNING (2): These are errors that don’t crash your app. Most errors seem to be at this level.

• E_USER_ERROR (256): A user-generated version of the above fatal error. This is often generated through trigger_error().
• E_USER_NOTICE (1024): A user-generated version of an informative event. This usually has no adverse effect on the app, much like a log.info().

The final category of note is the app lifecycle errors, usually with “core” or “compile” in the name:

• EE_CORE_ERROR (16): Similar to the fatal errors above, this error can only occur when the PHP application starts up.
• EE_COMPILE_WARNING (128): A nonfatal error that only happens when the PHP script fails to compile.

There are a few other errors. You can find the entire list of them here.

PHP display errors

Displaying error messages in PHP is often a confusing topic. Just google “PHP error message display” and see. Why is that the case?

In PHP, you can decide whether or not to display errors. This is different from reporting them. Reporting them will ensure the errors are not swallowed. But displaying them will show them to the user. You can have PHP display all errors by using the display_errors and display_startup_errors directive:

php  ini_set('display_errors', 1);  ini_set('display_startup_errors', 1); ?> 

Turning these on will ensure they show up in the body of the web response to the user. It’s usually a best practice to turn these off in nondevelopment environments. The integer method parameter is also a bitmask, like in error_reporting() . The same rules and options for that parameter also apply here.

What is a PHP warning?

You’ll note above that one of the error levels is E_WARNING . You may also have noted that many of the error levels have warning versions. I want to dig into this a bit. The main difference between a warning and an error in PHP is whether or not it ends the application. In PHP, most errors don’t actually stop the script from executing.

php  $x = 1;  trigger_error("user warning!", E_USER_WARNING);  $x = 3;  echo "$x is $$x>"; ?> 

You will still see $x is 3 despite triggering the warning. This can be useful if you want to collect a list of validation errors. I personally prefer to use exceptions these days, but your mileage may vary.

You can have PHP show warnings or not, of course. For that, you’d use the ‘display_errors’ configuration you’ve seen in the previous section.

How Crash Reporting helps

PHP makes it easy to set up external error reporting tools, like those offered by Raygun. It provides a few different hooks into its runtime to handle errors and send them over the wire. See this example, torn from Raygun’s PHP page:

namespace   // paste your 'requires' statement   $client = new \Raygun4php\RaygunClient("apikey for your application");   function error_handler($errno, $errstr, $errfile, $errline )   global $client;  $client->SendError($errno, $errstr, $errfile, $errline);  >   function exception_handler($exception)    global $client;  $client->SendException($exception);  >   set_exception_handler('exception_handler');  set_error_handler("error_handler"); >

First, we declare the client, using an API key for security:

 $client = new \Raygun4php\RaygunClient("apikey for your application");

Then we create a couple of functions that handle our errors and exceptions:

 function error_handler($errno, $errstr, $errfile, $errline )   global $client;  $client->SendError($errno, $errstr, $errfile, $errline);  >   function exception_handler($exception)    global $client;  $client->SendException($exception);  >

Note we call the SendError() function, passing in a few relevant details about the error data structure. This will make a remote call to Raygun.

Finally, we hook these into PHP’s runtime by globally handling both traditional errors and the newer exceptions:

set_exception_handler('exception_handler'); set_error_handler("error_handler");

And that’s it. With this all in place, we can get beautifully formatted error reporting that can look like this:

Wrapping up PHP error reporting

As you can see, PHP error reporting is straightforward. You can trigger exceptions through special functions. You can also trigger exceptions, like in other typed languages.

It’s easy to plug in your own handlers and control the reporting and display of errors. This lets us plug in Raygun’s tool with little effort — feel free to sign up for a Raygun trial and add it to your application in minutes.

Источник