The first point is a documented change:
http://php.net/migration71.incompatible#migration71.incompatible.error_log-syslog
> If the error_log ini setting is set to syslog [0], the PHP error levels are mapped to the syslog error levels.

The second point ("Was this difference in behavior between message type 0 and 4 intended?") is still questionable.

Thank you for your response, requinx. However, I do not believe your link/quote addresses the first issue I've raised. I'm specifically discussing the scenario when the error_log INI directive is unset, not when it is set to syslog. Further, my complaint is not that PHP error levels are mapped to Apache error levels. I acknowledged that as a documented, desired change in the opening of my bug description. My complaint is that when error_log INI is unset, and using the Apache SAPI, simple calls to the error_log() function such as error_log('message') are now Apache 'notice' level. Previous to 7.1 they were 'warn' level. In the linked PR it was suggested they should be 'error' level: https://github.com/php/php-src/pull/1981#issuecomment-361684885

Regarding the inconsistency in severity when explicitly sending the message to SAPI logger as opposed to letting it fall there by default because error_log INI directive is unset, that inconsistency would be... odd, if intended. But, if that were the case it should at least be documented. The author of the PR seems to suggest it was unintended: https://github.com/php/php-src/pull/1981#issuecomment-360932281

I think with the syslog/SAPI juggling between error_log() and error_log I managed to get the two of them mixed up. So ignore what I said.


tl;dr: IMO errors becoming notices is intentional and should remain but needs to be documented, while the 0/4 behavior should be fixed so that either error_log() with 4 explicitly logs as a notice or all messages are errors.


Here's an unnecessarily in-depth analysis of everything.

As of that PR 1981, error_log() with default/0 explicitly classifies as a notice (unchanged) and with 4 classifies using the logging's default which is as an error for Apache (unchanged). Additionally the SAPI error logger is capable of differentiating between PHP's error levels when that information gets passed through (new). That "gets passed through" happens when error logging goes through the error_log setting, and not through error_log() since that doesn't receive any severity information.

The result is the two differences you pointed out:
1. Previously, error_log() with default/0 had tried to log as a notice, however if the error went through the SAPI (meaning error_log is unset or empty) then Apache's behavior of forcing an error took over. Now, error_log() still tries to use a notice as before but this time Apache will respect that.
2. Now that SAPIs can respect the error level, to keep backwards compatibility the Apache logger uses error as the default level and error_log() with 4 will indicate the default level.

In other words,
- error_log() with default/0 and error_log *set* will log as a notice (unchanged)
- error_log() with default/0 and error_log *unset* will log as a notice (unchanged) but Apache will honor that (new)
- error_log() with 4 will log as the default level which to Apache means an error (unchanged)

The docs I linked before talk about syslog and come from the unrelated PR 1702:
  https://github.com/php/php-src/pull/1702

1981 is not mentioned in the migration guide, but both are stated in the 7.1.0 changelog as
  Implemented logging to syslog with dynamic error levels.
  Added PHP to SAPI error severity mapping for logs.

So,

The first point (messages are now notices instead of errors) is an undocumented but clearly intentional change. Really, I would say that trigger_error() is more appropriate for error situations than error_log() is to begin with - especially if you want to consider attaching a significance to the message's severity. This is a slight break to BC but it's now been more than a year since 7.1.0 was released so I think this should be left in place and documented in the migration log alongside the other comment.

The second point (default/0 and 4 are different) is still questionable. I think I agree that the only apparent difference between the two - where the message gets sent, or rather the decision making process that results in the message going to the SAPI in both cases - should not affect the severity of the message. Given the first point, I think error_log() with 4 should explicitly state an error level of notice. Alternatively *all* error_log() messages could go as errors. Both are easy changes. Preserving full BC by having messages go back to being errors *just for the SAPI* is more awkward to fix since execution goes through the general-purpose PHP logging facility and that would mean automagically changing severity from notice to error partway through.

I think that choice of notice or error boils down to whether error_log() is considered to mean "log an error message" and messages indicate problems, or more "log a message to the place errors get logged" and messages are informational.

requinx, thanks for your followup and extended analysis.

uncaught exceptions handled via `set_exception_handler` are not logged... unlike `set_error_handler`which is logged depending on the return value of the callback,

So I'd like to log the uncaught exception with `error_log()`...  which logs it as a "notice"..

There should be param (such as the `$additional_headers` param) to specify the severity/level)