I agree that currently it's better to change these back to real E_WARNINGS. I agree that exceptions should be thrown for things which we'd usually make E_ERRORs (if recoverable).
As most people here prefer not to go the route of exceptions, and I think many (not all) of their reasoning makes sense we should continue in the current direction of PHP (except for special cases such as SoapServer::handle() for example).
I think the ultimate solution will be to think of a way (possibly wrappers) to give the users a choice. For certain projects I do see great value in exceptions, but I don't think the average PHP user should be forced to work with them (especially as it's not an easy subject to implement correctly).
Andi
At 03:20 PM 4/16/2004 -0700, Sterling Hughes wrote:
Tidy's current error handling scheme is totally messed up - every single thing in the extension should be an E_WARNING by PHP standards.
Its RC2, and this stuff has worked for a long time, breaking it now is counterproductive and annoying.
John, if you insist on messing up the error handling in the tidy extension, which is a serious thing, why not move it to pecl where you have full control over such things without bothering the rest of the release..?
-Sterling
On Apr 16, 2004, at 9:44 AM, Derick Rethans wrote:
On Fri, 16 Apr 2004, Christian Schneider wrote:
John Coggeshall wrote:the best compromise I can reach without discarding exceptions entirely, which I believe is even more wrong for OO code.
I disagree. I lost track over the last couple of days, what is everyone else's view on this?
I disgree with this behavior too. E_WARNINGs were never supposed to abort a script, that's what we have E_ERRORs for. (Making E_ERROR an exception in an OO context is fine, as when it's unhandled it should abort the script, just like in PHP 4 and all other non-oo extensions).
Derick
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
