[wp-trac] [WordPress Trac] #59282: WordPress should register custom error and exception handlers

[WordPress Trac]

#59282: WordPress should register custom error and exception handlers
-------------------------------------------------+-------------------------
 Reporter:  bjorsch                              |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Bootstrap/Load                       |     Version:  6.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by bjorsch):

 Replying to [comment:14 jorbin]:
 > There are currently over
 [https://wpdirectory.net/search/01JYPSRVVEEYCZMTGQJECEFKVA 900 plugins
 that add an exception handler] and
 [https://wpdirectory.net/search/01JYPSWMKB3QZESDJ43RX92VR1 3453 that add
 an error handler]. A fairly large percentage of them don't implement
 calling a previusly registered handler.

 That doesn't tell the whole story though. If a plugin's exception or error
 handler exits or returns true, that's not a problem. If the plugin also
 somehow forces display_errors off, that also wouldn't be a problem for
 this particular change.

 And if it returns false, it could easily be argued that not chaining to
 any prior registered handler is already a bug in the plugin, since it's
 already overriding any other plugins' handlers.

 Plus, as SirLouen mentioned, it may still be worth improving Core even if
 some plugins will override the improvement.


 Replying to [comment:15 SirLouen]:
 > Anyway, I think I need to see in practice some real code example
 collisions and some test info in general for the proposed idea (apart from
 a bunch of text bullet points). It can take a while to research for this
 info for a tester, while, in theory, the reporter/patch maker should have
 this info available if he has been working on this topic. These
 theoretical proposals of code are a bit hard to digest, ngl. @bjorsch this
 report has had a `needs-test-info` status for more than a year, so now I
 don't wonder why this has been stuck for a good while. First, someone
 should have satisfied this for progress.

 "Needs-testing-info" was added even longer ago, but without any comment as
 to what, if anything, was needed from me. It was accompanied with a
 request for two people to look, who did not reply here or on the PR. I
 don't think you can legitimately blame the lack of progress here on me not
 providing something that was never asked for beyond the unexplained
 addition of a tag.

 For that matter, it's still not clear to me from your reply what "test
 info" you're asking for. Unit tests were added when that was requested on
 the PR back in 2023. What additional testing info are you looking for?
 Instruction that you could arrange for warnings or errors (containing
 unescaped HTML) to be raised, with various configurations for PHP's
 display_errors and other ini settings, and see that HTML (if any) returned
 to the browser is properly escaped while log files don't have unnecessary
 escaping? Are you needing more detail than that? If so, please in turn be
 specific about what detail you need. 🙂

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59282#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform