Bug Description

Escaping should normally be done close to the point of output (or at least the point where HTML is being generated). The WordPress.Security.EscapeOutput sniff instead encourages escaping at the point where exceptions are generated, without knowing if the exception is going to be caught, or output to a CLI, or logged to a text-based log, etc.

Apparently this is because someone was worried about people having display_errors on (which is PHP's default) and html_errors off (which is not the default). The sensible thing would have been to have WordPress use set_exception_handler() to set a default exception handler early in the request, which could easily ensure any output of the exception message to the browser is escaped even on such misconfigured sites and which would also catch errors generated by PHP itself and errors generated by other libraries that don't use WPCS.

I note a similar argument could be made for WPCS's insisting on trigger_error() having escaping rather than having WordPress use set_error_handler(). Although in that case html_errors being on doesn't prevent the problem.

Minimal Code Snippet

The issue happens when running this command:

phpcs --standard=WordPress-Extra

... over a file containing this code:

throw new Exception( "Text is $text" );

Error Code

WordPress.Security.EscapeOutput.OutputNotEscaped

Custom Ruleset

Use --standard=WordPress-Extra

Environment

Additional Context (optional)

Tested Against develop Branch?

• I have verified the issue still exists in the develop branch of WordPressCS.