On Thursday, March 27, 2003, at 12:10 PM, Timm Friebe wrote:
On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:On Thursday, March 27, 2003, at 11:58 AM, Andi Gutmans wrote:[...]I think this can(all) be handled with a custom zend_error_cb anyway (in
an extension - so that it's available only if you want it.) Looks
really simple to implement too.
Well, I can think fo the following disadvantages to that: - Code is less portable (some other user or ISP might not have the fancy --with-cool-oop extension enabled)
Well, as Andi said, most people do not use oop with php. Having the same thing available as a php.ini toggle would be just as easy, but doesn't sound like it would be popular.
- Within zend_error, all information is lost about the error context. E.g., if you handle E_ERROR, you will not know if it was an illegal argument, a call to a member function of a non-object or whatever else. You only know it was a fatal error.
This isn't completely true.
- Current code relies on the fact that zend_error(E_ERROR, [...]) bails out. If you start throwing around exceptions instead, this will probably end up in a big mess:)
Well, if you don't handle E_ERRORs correctly it will fuck things up. It's an exception, it means something broke. There's no reason why you can't recover/or at least gracefully handle most non-compile E_ERRORs, you just need to handle it correctly. If you don't you get what you're asking for.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
