[wp-trac] [WordPress Trac] #57842: Add a new independent WP_Exception class, compatible with WP_Error

WordPress Trac noreply at wordpress.org
Tue Aug 5 16:52:04 UTC 2025


#57842: Add a new independent WP_Exception class, compatible with WP_Error
-------------------------+------------------------------
 Reporter:  junaidbhura  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by dmsnell):

 Thanks @junaidbhura for proposing this.

 First of all, the patch itself seems rather harmless. You covered what was
 also my first thought — interaction with `WP_Error`.

 As per the architectural part though, I think it would be useful to
 motivate this change more.

 > I don't think I will need to elaborate the benefits Exceptions bring
 into modern development on this ticket.

 You wrote this in the description, but I think it might reveal some
 assumptions you could be bringing into the discussion. For one, exception-
 based errors are already possible in WordPress code. Yes, generally they
 are avoided to keep things running even when misbehaving plugins run.
 However, this change //hints// at a move away from `WP_Error`, yet
 intentionally doesn’t expand on that.

 I think it would be helpful to expand on that.

 In addition, maybe it would help to engage with a few basic questions I
 have:

  - Why is this preferred to `ValueError`, `TypeError`, `Error`,
 `Exception`? In other words, if the proposal is to push WordPress code
 //towards// Exceptions, what value does a custom exception bring to the
 table? Can you share some code examples that highlight it?

  - What is the functional goal of transforming into and out of `WP_Error`?
 Is it to provide a smooth transition, where a function throws and then a
 calling function returns the transformed value?

  - Did you consider adjusting `WP_Error` to extend `Exception` itself
 rather than creating a new `WP_Exception`? What would it look like in
 comparison if we could simply return or throw a `WP_Error`?

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


More information about the wp-trac mailing list