Gustavo, > Not really, that's just a convention that if zpp fails functions return null > or false immediately (which one is used depends on the extension, current > weather, etc.). That's because there's a convention that builtin functions > don't raise exceptions. But nothings stops them from falling back or > suppressing the warning/notice (and some do, esp. if they support distinct > sets of arguments). > > Some extensions (and constructors even in extensions that use false for > error) actually force an exception if zpp fails (usually via > zend_replace_error_handling).
Quite fair... > But of course this is not an option in user code because: > 1) you can't change the error handling before parsing the parameters and > 2) inside the function you can't tell whether some argument parsing error > occurred. Which is the point. > So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems in > fact the only viable option, even with the disadvantages it has > (centralization and lack of flexibility). So, at that point, then it sounds like we have a spec. Functionality of zpp, with an E_RECOVERABLE_ERROR where zpp would fail. Including any warnings or notices that zpp would have raised anyway (since `"1abc" would work when passed to an int, it should still work, notice intact). > Still, the fact that 100% consistency is not possible is not a strong > argument against at least *some* consistency and in favor of inventing new > rules. Sure. Makes sense. I'll work on a proof-of-concept this weekend. That is if nobody else wants to take it (or beats me to it) :-D. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
