Re: Re: Fw: setStub inconsistencies - dubious patch attached

Hi Greg,

I have a suggestion you may or may not like. Would it be possible to have an INI_ALL directive to use exceptions or standard errors? I'd personally have it with standard errors by default except in cases where there would be a fatal error anyway, which basically restricts exceptions-by-default to failures in the constructor. I don't think it matters greatly that the internal code is OO... Point being, if you're aiming for this to go into the PHP core, exceptions are literally the exception and not the rule there.

I am open to making this more flexible, but I'd prefer exceptions by default for the OO, and rather than use ini, allow per-process disabling via a static method, something like Phar::triggerErrors(), so that folks without access to ini can more easily control this.

Well, that's why I said INI_ALL. I think it would be harder to achieve via a static method - I can actually envisage a way of doing it (for a single extension, at least) via an INI setting because that's global. Tho' I have to say this is still at idea-level for me and I haven't experimented; there may be reasons this can't work.

On an unrelated rant, I've always hated PHP's native error handling, it's never made debugging easier for me, and often made it much more painful. Exceptions, with their easily accessed backtrace and error origin localization are much more conducive to proper debugging, as about 1/3 of the time the error is actually triggered by a logic error 2 or 3 method calls up the chain. Having that backtrace makes all the difference. Additionally, the ability to re-package an error - or multiple errors - into another abstract container is very handy, and just much harder to do or impossible with trigger_error.

Fine - when you're debugging. However when you're just running stuff you don't want or need 'uncaught exceptions' every time there's some minor thing out of place... Personally I like straight errors. I think there's a place for exceptions, but 'everywhere' isn't that place. But that's just a matter of preference, for both of us. The bigger issue is what people are used to having PHP do. - Steph

Greg -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php