In Dev Env should throw exception on deprecations

[ampmonteiro]

PHP Version

8.5

CodeIgniter4 Version

4.6.5

CodeIgniter4 Installation Method

Composer (using codeigniter4/appstarter)

Which operating systems have you tested for this bug?

Linux

Which server did you use?

fpm-fcgi

Environment

development

Database

No response

What happened?

Context:

i was reading code of some colleague, in my job, which find out that he was creating dynamic properties in controllers and in some models.

Strange is that i did not see nothing on screen about the deprecation of dynamic properties, which i knew about deprecation on 8.2+ as deprecation warning.

Steps to Reproduce

To make sure, i also create some dynamic properties in some random controller, when i found out that the warning was only showing / written on a log file but not show on screen.

Expected Output

In dev mode / env should show / throw exception on any kind of error on screen ( be a warning or not), because without a framework, it is what php does.

Should only show the kind of error on log file, only in prod.

How did make ci4 show this kind of errors:

just go to app > Config > Exceptions and change this $logDeprecations prop to:

public bool $logDeprecations = (ENVIRONMENT === 'production') ;

Anything else?

No response

[neznaika0]

It can be seen from the original commit #6705
v4.3 supported very old PHP 7.4 - 8.2
A deprecations could interfere with users.
Since this is a configuration setting, I don't think it's a bug. If the team decides that it's time, you can turn on the default display.

 /**
 * --------------------------------------------------------------------------
 * LOG DEPRECATIONS INSTEAD OF THROWING?
 * --------------------------------------------------------------------------
 * By default, CodeIgniter converts deprecations into exceptions. Also,
 * starting in PHP 8.1 will cause a lot of deprecated usage warnings.
 * Use this option to temporarily cease the warnings and instead log those.
 * This option also works for user deprecations.
 */
 public bool $logDeprecationsOnly = false;

[paulbalandan]

I think my PR description in #6773 is the reasoning you're looking for? As said by @neznaika0 , this behavior is configurable so should not be a bug. If you disagree with the reasoning, then you can simply turn $logDeprecations to false. Or you leave it as is, and then export the environment variable CODEIGNITER_SCREAM_DEPRECATIONS=1.

[ampmonteiro]

@neznaika0

It can be seen from the original commit #6705 v4.3 supported very old PHP 7.4 - 8.2 A deprecations could interfere with users.

I understood that, however, i am mentioning 4.6.x and 4.7.x not about 4.3.x.

As such, this change would be affecting this versions not 4.3.x.

Since this is a configuration setting, I don't think it's a bug. If the team decides that it's time, you can turn on the default display.

You can call even a bad default / decision, a missing configuration,whatever,
my perspective is bug, because, like the PHP language, frameworks should also show on screen, in Dev env,, all kind of errors / warnings / notices, etc, by default.

By showing this kind of errors, inform the user / developer, depends on PHP version, that needs or not update to latest version of framework or PHP language.

if your decision for now, this kind of default, is not a bug but a decision made by the maintainers,
for me, you can close the issue.

Thanks.

[ampmonteiro]

@paulbalandan

I think my PR description in #6773 is the reasoning you're looking for? As said by @neznaika0 , this behavior is configurable so should not be a bug. If you disagree with the reasoning, then you can simply turn $logDeprecations to false. Or you leave it as is, and then export the environment variable CODEIGNITER_SCREAM_DEPRECATIONS=1.

As i show, i change the configuration to this:

public bool $logDeprecations = (ENVIRONMENT === 'production') ;

I think, as you develop in dev mode, you should write correct code indicated by the language, like context i show, you should not create dynamic props.

And the language itself show this kind of errors, even that do not stop execution.

Another example, correct me if i am mistake, in the PHP language if your are echoing a variable that doest not exist, php give a warning and will not stop the execution but the framework stop the execution:

PHP:

Framework:

In framework world should exist consistency and predictability.

For me is a bad default and a bug.

Like i already said:

if your decision for now, this kind of default, is not a bug but a decision made by the maintainers,
for me, you can close the issue.

Thanks.

[michalsn]

Another example, correct me if i am mistake, in the PHP language if your are echoing a variable that doest not exist, php give a warning and will not stop the execution but the framework stop the execution

Warnings are converted to exceptions by the framework's error handler, so execution stops unless they are handled. In other words, any error that is not ignored by error_reporting() will stop the framework's execution. This is a standard pattern used by other frameworks as well.

[ampmonteiro]

@michalsn

In this case, it is not consistent.

Because when a variable is used but not declared, it shows on screen in Dev.

When is deprecation, only shows in a log file in Dev.

For me make no sense even less in dev mode. by default should show deprecation on screen, if the user / developer dont want that kind of strictness, than he should config as such not way around.

A framework, should help users/ developers, to organize and write better code.

About:

This is a standard pattern used by other frameworks as well.

When i have time, i will confirm, at least on another framework, what happen when is a deprecation.

Either way, my two cents, should be as before the change because of that issue (#6773) that @paulbalandan mention.

Since you remove the tag bug, feel free to close this issue, if you want.

Thanks.

[michalsn]

@ampmonteiro I understand that it feels inconsistent that one issue is visible immediately and another is only in logs.

This is an intentional tradeoff rather than a bug.

undefined variable usually means a direct runtime coding mistake. Deprecations are often "future compatibility" signals and can come from vendor code, so making them fatal/noisy by default can overwhelm teams after PHP upgrades.

We intentionally chose "less disruptive by default" for deprecations, but it is configurable for teams that want stricter development settings.