Re: exceptions instead of errors

The issue though is that almost none of the E_ERRORs in the engine are actually really fatal. I agree that the issue of things which are currently E_WARNINGs is complex (I personally think they should be handled by wrapper implementations that throw exceptions or vice-versa, but I think that is an issue for a different discussion), but the E_ERROR behavior change is completely clean and does not jeopardize BC at all. George On Tuesday, May 13, 2003, at 08:52 AM, Zeev Suraski wrote:

When I told Marcus that this whole business is far from being trivial, that's exactly what I meant. And that's why we haven't added the exceptions-for-errors at the same time we implemented exceptions, and why Andi said a few days ago that it shouldn't be introduced without further discussion. In my opinion, exceptions-for-errors at the language (ini) level should be removed. Instead, we should leave that entirely to userspace. People will be able to write their own error handler, and throw an exception if they wish. That gives them more granularity (they can selectively throw an exception). It's going to be especially useful if we go back to one of our old ideas, which is assigning each error with its own unique idea, and would be even more useful if we give each extension its own designated range of error codes. If we go in that direction, it would probably make sense to introduce a new error level in between E_ERROR and E_WARNING, that is fatal, but catchable by the error callback. Zeev At 12:05 13/05/2003, Alan Knowles wrote:

A very difficult problem with very little in the way of clean solutions.. my only thought was: mysql::connect() would thrown an exception mysql_connect() would emit an error.. basically all 'object methods - static or dynamic' would be expected to throw errors, where as functions would just emit errors. so you could implement object wrappers for key 'exception em It's far from a complete solution. (downside is the extra documentaiton overhead of this..) Regards Alan

Then pick some other way you like, there're surely several ways to reach the same ends. It's just an example of the kind of thing that would solve that problem without creating new problems. Personally, I'd say use new function names for exception-throwing versions of old functions, or stick exception-throwing wrappers in PEAR.

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com -- 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