Andi Gutmans wrote:
I think the main reason for all of this disagreement, is because PHP (pre-exception state) is not consistent with its error levels. As mentioned here, sometimes relatively serious errors are E_WARNINGs and some less serious errors are E_ERRORs. Now say, we'd map all E_ERRORs (which can be recovered from) to exceptions, functionally this would not be very problematic because for people not using exceptions they'd still get a fatal error and it would allow people who want to work with exceptions to take advantage of them. However, as stated the fact that PHP is inconsistent with its error levels would probably limit the usefulness of such a change because it'd probably lead to quite a few inconsistency.

I think the people here who argue that exceptions suck are quite wrong. In most cases, you expect your code to work perfectly. If it doesn't, I don't think you usually want it to continue its regular control flow. Rather, it'd be easier to catch the exception and give some kind of useful error message. Exceptions allow you to get rid of all of those if() statements that check function return values (due to it being a headache many developers leave those out) and to handle errors in a centralized place for logging and outputting a nice error screen. After all they should be used for real errors and not for control-flow. I think people who argue that exceptions suck probably aren't the people who check every return code of their functions or they'd be completely pissed off with that error model.

I don't think that exceptions suck, but I agree that they are limited in their usefulness, just as you describe in the first paragraph. The majority of error conditions aren't severe enough to need them. Unfortunately, many developers I have talked to about exceptions plans to use them for just about every kind of error condition, and they expect them to be useful as such.


I suspect this is because it is possible to differentiate between error type, and even severity, just through the class of the exception. Perhaps some kind of non-fatal exception equivalent could be worked out for 5.1/5.2?

if continue or return was extended to allow returning from a catch to the point of execution after the throw statement, this would of course open a can of worms, but it might solve the issue. Obviously this would have to fail for any internal throw(), and be possible for user-level throw() only. Alternatively, it could return to the first user-level statement following the internal throw().

Greg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to