Discussion:
Why WP_Error Sucks
(too old to reply)
Ryan McCue
2012-07-24 12:56:48 UTC
Permalink
Hi 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 ;) ).

Cheers,
--
Ryan McCue
<http://ryanmccue.info/>
Otto
2012-07-24 13:11:12 UTC
Permalink
Exceptions and try/catch don't parse in PHP 4 environments, leading to
fatal parsing errors.

-Otto
Post by Ryan McCue
Hi 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 ;) ).
Cheers,
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ryan McCue
2012-07-24 13:21:21 UTC
Permalink
Post by Otto
Exceptions and try/catch don't parse in PHP 4 environments, leading to
fatal parsing errors.
I replied to your comment on my post, but to reiterate here: that's only
a problem for the very few files that are loaded before WP checks for
PHP 5+. These are small enough that it doesn't really matter (and is
really no different to protected/private keywords, etc).
--
Ryan McCue
<http://ryanmccue.info/>
Harry Metcalfe
2012-07-24 13:16:27 UTC
Permalink
Did someone post some stats recently about what versions of PHP in use by WP sites?

I completely agree that exceptions would be better, but presumably, that has to wait until so few people are still on PHP4 that we can make PHP5+ a requirement.

Harry
Post by Ryan McCue
Hi 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 ;) ).
Cheers,
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ryan McCue
2012-07-24 13:20:03 UTC
Permalink
Post by Harry Metcalfe
I completely agree that exceptions would be better, but presumably, that has to wait until so few people are still on PHP4 that we can make PHP5+ a requirement.
WordPress currently requires PHP 5.1.4+, as of WP 3.2:
http://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/
--
Ryan McCue
<http://ryanmccue.info/>
Harry Metcalfe
2012-07-24 14:30:34 UTC
Permalink
Ah. That'll teach me to post without checking :)
Post by Ryan McCue
Post by Harry Metcalfe
I completely agree that exceptions would be better, but presumably, that has to wait until so few people are still on PHP4 that we can make PHP5+ a requirement.
http://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
William P. Davis
2012-07-24 13:20:21 UTC
Permalink
PHP5 is required in recent versions of WordPress, so I would agree that WP_Error should use exceptions. I would urge you to submit a patch to Trac.

Will
------Original Message------
From: Harry Metcalfe
Sender: wp-hackers-***@lists.automattic.com
To: wp-***@lists.automattic.com
ReplyTo: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] Why WP_Error Sucks
Sent: Jul 24, 2012 9:16 AM

Did someone post some stats recently about what versions of PHP in use by WP sites?

I completely agree that exceptions would be better, but presumably, that has to wait until so few people are still on PHP4 that we can make PHP5+ a requirement.

Harry
Post by Ryan McCue
Hi 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 ;) ).
Cheers,
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-***@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers

Sent from my BlackBerry
Ryan McCue
2012-07-24 13:23:06 UTC
Permalink
Post by William P. Davis
PHP5 is required in recent versions of WordPress, so I would agree that WP_Error should use exceptions. I would urge you to submit a patch to Trac.
I didn't mention it in the post, but this has been previously discussed:
http://core.trac.wordpress.org/ticket/16769

The idea of this post was to get the idea out there, see if there's any
good points against implementing it, and then to begin that process.
I'll happily contribute a patch, but at the moment, I don't see it as a
possibility.

I'd love to hear from core committers/contributors on what they'd think
about it.
--
Ryan McCue
<http://ryanmccue.info/>
Ryan WP Mailing Lists
2012-07-24 13:43:38 UTC
Permalink
As a caregivers from my .net programming I use and am comfortable with the
concept of exceptions. WP_Error on the otherhand I just don't quite get. In
fact I admit I don't implement it in my plugins, not that it matters since
I have never made a pouting for public release but still.

I like the idea and honestly now that PHP supports it with version 5 why
not as it is the dare I say "correct" method of error handling.
Post by Ryan McCue
Hi 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 ;) ).
Cheers,
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Otto
2012-07-24 14:15:50 UTC
Permalink
On Tue, Jul 24, 2012 at 8:43 AM, Ryan WP Mailing Lists
Post by Ryan WP Mailing Lists
As a caregivers from my .net programming I use and am comfortable with the
concept of exceptions. WP_Error on the otherhand I just don't quite get. In
fact I admit I don't implement it in my plugins, not that it matters since
I have never made a pouting for public release but still.
I like the idea and honestly now that PHP supports it with version 5 why
not as it is the dare I say "correct" method of error handling.
Okay, I would let this go, but... argh. "Correctness" is relative.

IMO, Exceptions suck rocks. This applies to every language they're
implemented in.

The base problem I have with Exceptions is that they should be used
for error handling, but what they invariably end up being used for is
program logic.

Exceptions, when you break it down, are a way to have a return value
from a function that is outside the normal scope of what the function
returns. If a function is supposed to return an integer value, but
something happens where it needs to signal the calling code something
else, then there's two ways to handle it:
a) special return values - this is harder in a strongly typed language
where the return value must fit into an int, for example. PHP is not
such a language.
b) Exceptions, where you "throw" an error condition and expect the
calling code to wrap in a try/catch to handle that special condition.

With a, at least you can define things as such that the calling code
will have to properly handle them. With exceptions, the calling code
can optionally handle the problem or just pass the Exception up the
call stack.

What this generally means is that you have some lazy coder ignoring
the Exceptions, and then a higher level code doing try{ } catch (
Exception e ) { } to just catch them all like some demented Pokemon
cartoon.

Furthermore, Exceptions should be exceptional, meaning that they
should be errors, basically. If I call a function and it throws an
Exception, then I'm presumably expected to handle that exception case
in some manner, to resolve the error. However, if I could have done
that, then I probably should have done it to begin with, and if I was
capable of eliminating the error possibility, then I don't need to
handle the exception case anyway. Meaning that all *real* Exceptions
in the world end up going back up the call stack and just presenting
some error to the user. So when Exceptions are useful, then they're
useless. By design.

While you can attribute a lot of this to shitty programmers, I think
Exceptions themselves encourage this sort of poor and lazy coding,
honestly. They don't encourage "defensive" coding, by which I mean to
write your code so that the error conditions are handled from the
actual program logic. Instead, the existence of Exceptions and
exception handling encourages developers to simply catch "expected"
exceptions and then ignore them in order to make the compiler happy.
This leads to poor code, difficulty of debugging, and general
crappiness. Look at virtually all Java code. Most .NET code is worse,
but harder to find anybody using (bad Java is somewhat everywhere).

This comes about mostly because Exceptions intentionally break
encapsulation. In order to handle an exception properly, I need to
know something about the implementation of the code that threw the
exception to begin with. Poor object oriented design.

So yeah, I hate 'em. Especially in PHP where we're not limited to
strict typed return values. I can return an int, a string, an object,
whatever I like. As long as it's defined well, and it's easy for the
calling code to discriminate between the expected return value vs a
WP_Error object, then Exceptions don't offer me much except for that
breaking of encapsulation, which I don't see as necessarily a good
thing.

-Otto
Brian Layman
2012-07-24 15:32:25 UTC
Permalink
While I won't say I hate them, I agree completely with Otto that
"Exceptions should be exceptional". When you look at the extra load an
exception handling adds to your program, you realize that they should be
be avoided at almost all cost. Unfortunately that means a lot of extra
effort on our part to actually do things right in the first place -
adding the if statements to look for what will cause the errors and
building the logic to properly handle the work flow. The problem is
that this kind of coding is work and not fun. It's tedious.
Additionally each time something comes through and is raised as an
exception, that means there is more code you need to write to fix that
exception.

I've not seen any performance tests on PHP to show the speed difference
of if blocks vs exceptions, but I would be shocked if PHP somehow
handled exceptions with more efficiency than any of the other languages
I've worked in.

Brian Layman
Andrew Nacin
2012-07-24 16:31:17 UTC
Permalink
On Tue, Jul 24, 2012 at 11:32 AM, Brian Layman
I've not seen any performance tests on PHP to show the speed difference of
if blocks vs exceptions, but I would be shocked if PHP somehow handled
exceptions with more efficiency than any of the other languages I've worked
in.
Nope, they're terribly slow in PHP too. Which is fine if they're only used
for catching critical failures ("exceptional" circumstances). That's not
the case with our WP_Error usage (as I summarized).
Ryan WP Mailing Lists
2012-07-24 17:30:22 UTC
Permalink
I guess given my experience with .net I was tought exceptions so I really
don't know better I guess. I also don't really understand WP_Error. Does
anyone know of a good overview of it I could have a look at?
Post by Brian Layman
While I won't say I hate them, I agree completely with Otto that
"Exceptions should be exceptional". When you look at the extra load an
exception handling adds to your program, you realize that they should be be
avoided at almost all cost. Unfortunately that means a lot of extra effort
on our part to actually do things right in the first place - adding the if
statements to look for what will cause the errors and building the logic to
properly handle the work flow. The problem is that this kind of coding is
work and not fun. It's tedious. Additionally each time something comes
through and is raised as an exception, that means there is more code you
need to write to fix that exception.
I've not seen any performance tests on PHP to show the speed difference of
if blocks vs exceptions, but I would be shocked if PHP somehow handled
exceptions with more efficiency than any of the other languages I've worked
in.
Brian Layman
______________________________**_________________
wp-hackers mailing list
http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
scribu
2012-07-24 18:58:25 UTC
Permalink
On Tue, Jul 24, 2012 at 8:30 PM, Ryan WP Mailing Lists <
Post by Ryan WP Mailing Lists
I also don't really understand WP_Error. Does
anyone know of a good overview of it I could have a look at?
It's just a class. The best overview you'll find anywhere:
http://core.trac.wordpress.org/browser/trunk/wp-includes/class-wp-error.php
--
http://scribu.net
Andrew Nacin
2012-07-24 14:46:03 UTC
Permalink
Post by Ryan McCue
Hi 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
Ryan McCue
2012-07-25 06:47:52 UTC
Permalink
Post by Andrew Nacin
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.
To clarify what I said in the blog post: the idea of putting them inside
do_action/apply_filters would be to avoid calling wp_die() and instead
letting just that callback fail.

At the moment, a lot of developers forget about WP_Error (at least, in
the plugin audits I've done). This means that it actually causes a
warning (attempting to access object as array, e.g.) or worse, gives bad
data.
Post by Andrew Nacin
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.
Definitely agree. There are plenty of places where it does make sense to
use WP_Error instead of an exception. I stereotyped all errors in my
blog post to be the type suiting exceptions, because there are a lot
that are. For those that aren't, WP_Error should be used instead,
although in some cases, a more specific class might be more useful.

As for the multiple errors/extra data, both of those are possible with
exceptions. Exceptions are still normal objects.
Post by Andrew Nacin
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.
I also agree here, but only for certain cases:

- cURL/fsockopen/Stream errors should be exceptions. These are things
which should be raised, as they are a failure regardless of use case

- HTTP errors (i.e. non-2xx status codes) should not be exceptions,
unless the caller specifically asks for them to be. For example,
Requests [0] has a `throw_for_error()` method on the response object;
Mike suggested an 'exception' option, which would also work great.

The reason for this is because it's dependent on the caller as to
whether one of these statuses is a failure mode.
Post by Andrew Nacin
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.)
It's less about being lazy and more about handling it where it makes
sense, rather than having to handle it at every stage.
Post by Andrew Nacin
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.
Why not include a mock WP_Exception within that? We already have mock
functions in wp-admin/load-scripts.php and wp-admin/load-styles.php.

On top of that, we could just use Exception itself. The functions that
have it available could use WP_Exception, and the other functions could
use Exception; the calling code could then catch all of them with `catch
(Exception $e)`
Post by Andrew Nacin
The second problem is that PHP doesn't have finally blocks.
I do agree with that, and I'm not a fan of that, however they are
working on that (it looks likely that it'll make it into 5.5, and
possibly 5.4). That doesn't make much of a difference to us, but you can
fake it in the few cases where you actually need it:

try {
$fp = fopen('readme.txt');
some_function_that_throws_an_exception($fp);
fclose($fp);
}
catch (Exception $e) {
fclose($fp);
throw $e;
}

It does involve duplication, but it's still possible, and I think it's
used infrequently enough that it's not too much of an issue.
Post by Andrew Nacin
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.
WordPress is well-known throughout a lot of the PHP community for being
fairly horrible from a PHP standpoint. This has been changing as WP gets
modernised and I think part of that is embracing the facilities we have
in PHP.

I also think this will benefit plugin authors, especially the weaker
ones. A lot of them don't bother to check `is_wp_error()`. Exceptions on
the other hand make it very obvious when an error has occurred, and are
much less obscure than a "cannot use object of type WP_Error as array"
error.

Theme developers/designers should never need to handle that. Exceptions
don't make sense for any of the template tags (e.g.), only the more
low-level stuff.
Post by Andrew Nacin
And of course, plugin authors can already use exceptions if they wanted to.
And they should, hence why I wrote about converting WP_Error to
exceptions now. I already do this myself. :)
Post by Andrew Nacin
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. :-)
Actually, my plan was to write a wrapper for Requests [0] to make it
expose a WP_Http-like API, including WP_Error support (so basically, in
the other direction). Convolution FTW! :D

Thanks for the detailed response!


[0]: http://requests.ryanmccue.info/
--
Ryan McCue
<http://ryanmccue.info/>
Michael D Adams
2012-07-24 14:58:21 UTC
Permalink
Post by Ryan McCue
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.
Joel Spolsky's opinion:
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
Almog Baku
2012-07-24 15:10:44 UTC
Permalink
According to the official requirements wordpress require php5.2.4(if
you ask me it really great time to upgrade this require to 5.3/5.4 for
the new release of wordpress ver. 3.6).

So- By this argument.. I totally agree. I think exceptions will be much better.
Post by Michael D Adams
Post by Ryan McCue
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.
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Amy Hendrix
2012-07-24 15:12:51 UTC
Permalink
Not likely to happen while 72% of the installed base is on 5.2
Post by Almog Baku
According to the official requirements wordpress require php5.2.4(if
you ask me it really great time to upgrade this require to 5.3/5.4 for
the new release of wordpress ver. 3.6).
So- By this argument.. I totally agree. I think exceptions will be much better.
Post by Michael D Adams
Post by Ryan McCue
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.
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ferenc Gergely Szilagyi
2012-07-24 15:14:05 UTC
Permalink
Requiring PHP5 to run doesn't means that you also must use all PHP5
features, just because they are there.
Post by Amy Hendrix
Not likely to happen while 72% of the installed base is on 5.2
Post by Almog Baku
According to the official requirements wordpress require php5.2.4(if
you ask me it really great time to upgrade this require to 5.3/5.4 for
the new release of wordpress ver. 3.6).
So- By this argument.. I totally agree. I think exceptions will be much better.
Post by Michael D Adams
Post by Ryan McCue
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.
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ryan McCue
2012-07-24 22:36:31 UTC
Permalink
Post by Almog Baku
According to the official requirements wordpress require php5.2.4(if
you ask me it really great time to upgrade this require to 5.3/5.4 for
the new release of wordpress ver. 3.6).
So- By this argument.. I totally agree. I think exceptions will be much better.
I'd just like to note for anyone reading these posts: exceptions were
added to PHP in 5.0, not 5.3. It's easily possible for WP to start using
them now from a technical standpoint.
--
Ryan McCue
<http://ryanmccue.info/>
Andrew Nacin
2012-07-24 16:34:44 UTC
Permalink
Post by Michael D Adams
Post by Ryan McCue
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.
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
Ah, yes, I was looking for this link. Thanks, Mike. Anything that Otto, I,
and others didn't cover, is dealt with there.
Mike Schinkel
2012-07-24 23:01:35 UTC
Permalink
There are good points on both sides of this issue; exception handling is both useful and a nightmare, depending on how it is used.

Exceptions are very useful when dealing with local complexity in visible scope when external factors result in failed assumptions. Consider the following alternate take on Ryan's example[1]:

https://gist.github.com/3173032

it implies an updated wp_remote_get() that will throw an exception if passed $args['exception'] => true, otherwise it will return a WP_Error() like it currently does. This would only require that functions in core which are likely to fail because of external factors be changed to request an exception thrown instead of returning an error (there are only a few such functions that might need this.) Basically this approach removes the injected dependency which is what I think most people have issue with.

This would be 100% backward compatible, it would address Ryan's reasonable concerns, and it would not infect core with exceptions. If best practices were documented in Codex, i.e. only use WP_Exceptions when everything about the exception's effects are visible in the current function then Codex tends to be rather influential among plugin developers to keep most everyone from _doing_it_wrong().

FWIW.

-Mike
P.S. The example shown doesn't illustrate the level of complexity where exceptions would really help, i.e. with numerous calls to wp_remote_get() or other functions that are likely to fail. Basically anywhere you have to do complex interactions with a web API, FTP server or other web service.

[1] http://journal.ryanmccue.info/165/why-wp_error-sucks/
Post by Andrew Nacin
Post by Michael D Adams
Post by Ryan McCue
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.
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
Ah, yes, I was looking for this link. Thanks, Mike. Anything that Otto, I,
and others didn't cover, is dealt with there.
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ryan McCue
2012-07-25 06:57:45 UTC
Permalink
Post by Michael D Adams
http://www.joelonsoftware.com/items/2003/10/13.html (Exceptions are
worse than GOTOs)
While I'm a big fan of Joel's writing, I don't always agree with him on
his topics. This is one of them.

Not knowing whether a function is going to throw an exception seems to
me like more of a documentation issue than anything else. I think that's
definitely solvable, especially given WordPress' fairly good PHPDoc that
we already have.
Post by Michael D Adams
It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking, but that's life
I disagree that it has to be this way. We're using a modern high-level
development language with these features built in.
--
Ryan McCue
<http://ryanmccue.info/>
Loading...