Post by Ryan McCueHi hackers!
I just posted a blog post regarding WP_Error, and why it (quite frankly)
sucks: http://journal.ryanmccue.info/165/why-wp_error-sucks/
I'd be interested to hear your thoughts on WP_Error and the possibility
of using exceptions as well. I'd also love to hear from anyone who has
implemented exceptions in their own plugin code.
(Bonus points if you're a core developer, especially if you're westi ;) ).
WordPress, for better and sometimes for worse, has its own way to doing
things. WP_Error has served us well. Refactoring areas of the codebase to
use and handle exceptions just doesn't make a lot of sense right now. Not
when we strive for backwards compatibility, and not when we put users
first. As you said in your article, it wouldn't be a fun or particularly
safe conversion. It is a good rule of thumb to actually benefit from such
overhauls. I'd rather invest my time in a lot of other architectural
projects.
You also mention the idea of putting try/catch inside of the plugin API —
that would be terribly slow, and defeats the purpose of forcing exceptions
on developers. Congratulations, a plugin developer didn't code for an
exception because they knew core would catch it and issue a wp_die()
message, like that error would ever happen anyway. No thanks.
We use WP_Error for probably three distinct things:
1. As return codes. Often, WP_Error is used when the error is not
"exceptional." It enables you to pass multiple errors, and also extra data.
Using WP_Error as a return value is nice in the authentication API, for
example. It is also very helpful as a value passed to filters, to then
either be modified or checked against by plugins. The action/filter
paradigm is almost unique to WordPress, and is what defines WordPress
development in many ways. WP_Error assists with that, in a far cleaner way
than an exception would. Even with exceptions, we would still want WP_Error
as verbose return codes, because don't get me started on bitwise operators.
2. As legitimate errors where exceptions could be used, but shouldn't be.
This kind of factors into return codes. I personally do not find a failed
HTTP request to be "exceptional" that, if uncaught, should result in a
fatal error. At the very least, it certainly depends on what you're trying
to do — an API request, or maybe just something in the background.
Sometimes, you actually just don't care about the return value of
something. But hey, that's just me.
3. As legitimate errors where exceptions can and should be used, but won't
be. Exceptions can be useful in particular instances in WordPress. For
example, during plugin/theme installation and upgrade, for core updates.
We're doing a ton with the filesystem here: downloading archives, verifying
and unzipping them, creating folders, moving files, setting permissions,
etc. Some code here is ripe for exceptions — otherwise, we're forced to
check, over and over again, that our most recent result isn't a WP_Error.
Wrapping all of this in a try/catch would be nice. (I think relying on
exceptions to bubble is lazy; we'd be handling these all within that
routine.)
However, two major problems with this. One,
wp-admin/includes/update-core.php is copied over during a core update and
executed by the currently installed version. Can't throw a WP_Exception
when WP_Exception doesn't exist yet. Since you can update across multiple
major versions at once, you can never really do this well without coding
around it. So, the one place where I could see a benefit to exceptions,
couldn't truly benefit from them without needless refactoring.
The second problem is that PHP doesn't have finally blocks. This is
absurdly stupid. We'd be using try/catch when dealing with filesystem
operations, in particular upgrades. That means we need to roll back, clean
up, release locks, whatever. If WP_Error sucks because it requires slightly
more code and forces programmers to defensively consider errors, rather
than letting everything bubble up, then it sucks. But if try/catch is
supposed to make the code cleaner, then the lack of finally really blows
that argument out of the water.
I'm not saying there isn't a single use in WordPress for a WP_Exception. I
know for a fact there are some, but I also don't think there are enough
examples where an exception would be oh-just-so-much-better than error
objects to justify a paradigm change. As it is, WordPress is getting
complicated (almost too complicated) in certain areas, and it'll only serve
to hurt theme developers, designers, and many weaker plugin authors the
more "by the book" we become.
And of course, plugin authors can already use exceptions if they wanted to.
Write your own HTTP API wrapper that throws exceptions — come on, you're a
programmer, do what programmers do: make a personal, convoluted abstraction
layer. :-)
Nacin