Request #69654: Add E_DEBUG and E_USER_DEBUG constants

[bzick]

Pull request for request #69654.
All loggers and project has [DEBUG] mode. Using E_NOTICE as debug identification is incorrect for dev-messages because in production dev-message must be ignoring and in dev-mode all messages (notices and debugs) mixed in mess.

Some extensions can use the constant E_DEBUG in their dev-messages. For example, MongoLog use E_NOTICE for debugging. It is not convenient. Zend Engine in dev-mode can use E_DEBUG and generate dev-message (we can get stack trace of memory leak messages).

For example

trigger_error("Connection to DB established", E_USER_DEBUG);

generates debug message

Debug: Connection to DB established in ...

[Danack]

I know people should haven't written code that is hard-coded against the value of E_EXCEPTION, but some people will have. Adding the two new values at the end of the list would break less stuff.

[bzick]

Hm, useful information. i'll research it

[bwoebi]

@Danack this is irrelevant … E_EXCEPTION is PHP 7 only and never exported as constant to userland.

[nikic]

Not a fan of this, I don't think this belongs into core.

[Kubo2]

@bzick Sounds pretty good. 👍

[bzick]

@nikic, i'm not a fan of that, too. However, there are several reasons why we should add these constants:

• Ability to generate debug messages from modules PHP, using constant E_DEBUG. Also we can get a stack trace of message. So it will be easier to understand why and where debug messages happened.
• PHP has a universal message system, which can use all packages of the application. Packages may not have their system logging (and should not) because it is problem the application. But there is no way to send debug-message.
• Make the message system complete. In any system exists debug-message except PHP. All levels of messages are well specified in RFC5424 and most logging systems support them except PHP:
  • EMERGENCY => E_CORE_ERROR (Emergency: system is unusable.)
  • ALERT => E_PARSE | E_COMPILE_ERROR (Action must be taken immediately. Example: Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up.)
  • CRITICAL => E_PARSE (Critical conditions. Example: Application component unavailable, unexpected exception.)
  • ERROR => E_USER_ERROR | E_RECOVERABLE_ERROR (Runtime errors that do not require immediate action but should typically be logged and monitored.)
  • WARNING => E_USER_WARNING | E_WARNING | E_COMPILE_WARNING | E_CORE_WARNING (Exceptional occurrences that are not errors. Examples: Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong.)
  • NOTICE => E_NOTICE | E_DEPRECATED | E_USER_DEPRECATED | E_USER_NOTICE | E_STRICT (Normal but significant events.)
  • INFO => may be E_USER_NOTICE (Interesting events. Examples: User logs in, SQL logs.)
  • DEBUG => ??? (Detailed debug information.)

(level descriptions taken from monolog)

[krakjoe]

Since no RFC materialized, I'm closing the PR.