--- title: "New PHP error messages in PHP 8.3" url: https://www.exakat.io/new-php-error-messages-in-php-8-3/ date: 2023-09-27 modified: 2023-12-03 author: "dams" description: "New PHP errors messages in PHP 8.3 The upcoming PHP 8.3 is bringing some new errors messages. They originate from new features, deprecated ones, and extra checks on the source..." categories: - "Code auditing" tags: - "audit" - "php" - "PHP 8.3" image: https://www.exakat.io/wp-content/uploads/2022/06/fenetre.320.png word_count: 1446 --- # New PHP error messages in PHP 8.3 # New PHP errors messages in PHP 8.3 The upcoming PHP 8.3 is bringing some new errors messages. They originate from new features, deprecated ones, and extra checks on the source code. Let's review the new PHP error messages in PHP 8.3 and get our code ready for November 2023. ## Previous review - [New error messages in PHP 8.2](https://www.exakat.io/en/new-php-errors-messages-in-php-8-2/) - [New error messages in PHP 8.1](https://www.exakat.io/en/new-error-messages-in-php-8-1/) - [Common PHP 8.0 Error Messages](https://www.exakat.io/en/common-php-8-0-compilation-error-messages/) ## Evolution of error message counts With distinct 783 error messages, PHP 8.3 is ranking number 4, bumping PHP 8.2 down one notch, and still far behind PHP 7.4 with its 824 distinct error messages. It is also more than PHP 8.2. [![Number of PHP error messages in PHP versions](https://www.exakat.io/wp-content/uploads/2023/09/error-messages-PHP-8.3-300x223.png)](https://www.exakat.io/wp-content/uploads/2023/09/error-messages-PHP-8.3.png) Usually, the distinct number of error messages grow within a PHP major version, as deprecations are accumulated until the next breaking change version: at that point, they are removed and the whole number drops significantly. We'll see what happens with PHP 9.0. ## New error messages PHP 8.3 adds 38 new error messages, and removes 11 of them, for a net increase of 27.     Quick disclaimer : the error messages are read from PHP code source, which is in C. In the messages, the `%s` is the placeholder for strings, just like with sprintf() in PHP. They usually carry a name, which is dynamically filled by PHP. Here are the most interesting new PHP error messages. ## Calling get_class() without arguments is deprecated ## Calling get_parent_class() without arguments is deprecated Calling get_class() without arguments was only allowed when called from within a class. Then, it would use the current class as the default, and returns its name. In PHP 8.3, get_class() and get_parent_class()'s arguments are now compulsory. It must be provided as argument. This means using `$this` when inside a class. Another option is to call get_called_class(), which acts as get_class() without arguments. get_called_class() also works with static methods, a.k.a. methods without access to `$this`. There is no such thing as get_called_parent_class() or get_called_class_parent() (sic). This is a changed behavior, with deprecation notice. It will be finalized in PHP 9. ## Cannot use %s as value for class constant %s::%s of type %s This error message is linked to the typing of class constants. In PHP 8.3, class constants may be typed. When this happens, the value of the constant must be of the assigned type. Of course, there are a wide range of possible error messages, depending on types. This is a linted error. [RFC](https://wiki.php.net/rfc/typed_class_constants) ## Class constant %s::%s cannot have type %s Another aspect of class constant typing is that not all types are possible. Obviously, common types like `int`, `float`, `array`, `bool`, `true`, `false`, `null`, `object`, any class, and any valid combinaison of those with union, intersection or DNF. On the other hand, some specific types are not possible: `never`, `void`, `callable`. The two first are quite obvious, while `callable` is forbidden to avoid confusing situations with actual method calls. This is a linted error. ## Cannot use the %s modifier on a %s Here, modifiers are options for class elements, such as `abstract`, `static`, `public`, `final`, etc. The class elements are properties, methods and class constants. When such elements get the wrong modifier, PHP used to emit a syntax error. Although this was simple to understand, the new error messages are now a lot more expressive. This is a lint error. ## Cannot use the abstract modifier on an anonymous class ## Cannot use the final modifier on an abstract method ## Cannot use the final modifier on an anonymous class Those are specific errors, related to anonymous classes. Anonynous classes can't be abstract as they won't be derived. They also cannot hold abstract methods for the same reason. Anonymous classes are always final by default, as they can't be derived. Even though, this message is an actual upgrade from a previous syntax error. This is a linted error. ## Increment on non-alphanumeric string is deprecated One of the open secrets of PHP is using the increment operator on strings. It actually increments strings to its next ASCII value, or it adds one to its value. Knowing that, the error message above looks like the death warrant of this feature. In fact, the reality is quite subtle. For starter, the above examples are still valid. Then, PHP still goes a long way to keep the feature working, by detecting numbers or valid incrementable strings, before reporting an error. Here is a selection of cases, sourced from the unit tests of PHP 8.3. It includes integers, floats, negative numbers, several types of strings: Most of the previous behaviors have been preserved. The last one, which generates the error, has a string which is not obvious to convert, because of the initial space. Multi bytes strings might also have the same behavior. To prepare for the future, such feature should be replaced by the dedicated str_increment() and str_decrement() functions, which handle these situations. They will stay compatible with future versions. There are more details about the evolution of this feature in the RFC below. [RFC](https://wiki.php.net/rfc/saner-inc-dec-operators) This is an execution error. ## Decrement on empty string is deprecated as non-numeric ## Decrement on non-numeric string has no effect and is deprecated ## Decrement on type bool has no effect, this will change in the next major version of PHP ## Decrement on type null has no effect, this will change in the next major version of PHP Specific error messages are introduced for the decrement operator. It already had no effect on strings nor boolean, and now, it is mentionned in the errors. ## Increment on type bool has no effect, this will change in the next major version of PHP If you have ever tried to apply the increment or decrement operator on boolean values, you may have noticed that it doesn't have any effect. Well, PHP 8.3 introduce a specific warning, that tells it to anyone who tries. The behavior is unchanged since PHP 7.0, but now, it is clearly stated. This is an execution error. ## Duplicate declaration of static variable $%s The variable used in the `use` clause of a closure represents a variable which is coming from the creating context. On the other hand, the closure may also declare a static variable (not a property), with the same name. That leads to confusion for the human and the developer alike. Now, this is reported at linting time. This is a lint error. ## Unknown errors Here are some errors which are in the source code of PHP, but we could not reproduce. If you have experience, you can share it with us. - `Maximum call stack size of %zu bytes reached during compilation. Try splitting expression` - `Throwing resource destructor called` - `cannot cancel the query: %s`. ## Get ready for PHP 8.3 Hopefully, this quick tour in the new error messages of PHP 8.3 will help preparing the code for its own migration to PHP 8.3. Since some of the checks are only available at execution time, it is worth running static analysis on it to spot potential errors. Exakat include the [Compatibility PHP 8.3](https://exakat.readthedocs.io/en/latest/Reference/Rulesets.html#compatibilityphp83) ruleset, with rules dedicated to PHP 8.3. They can run on PHP 8.2, so as to be ready for November 2023. Happy auditing.