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.
Personally, I am not sure what my take on this is as I think most of us agree that it's a mess and there's no perfect solution. In an ideal world, I would prefer to write DB connection/query/disconnection code without having to check their return values, and if an error occurs, catch that exception and give a meaningful error message. However, it seems that finding the right solution for PHP is going to be pretty hard.
Thinking out loud, it might be interesting to think of some automatic wrapping API, which could be used in order to use exception based PHP vs. regular PHP. However, doing this in a way which is accurate and automatic, especially as relying on our current E_* doesn't seem to be a good option, would be quite hard.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php