Exceptions in languages like Java are used explicitly to catch fatal errors, not to catch basic errors. Converting warnings to exceptions would change the meaning of a warning from something which is nice for development, or logging purposes, but handled by your control flow, into an unrecoverable error.
Exceptions enable the user (as in: the programmer as user of a certain API) to decide which conditions qualify as fatal and which do not. For example, an SQL parse error would be fatal in an app where the SQL is hardcoded, but would be a valid error condition in an app that allows user entry of SQL statements. Stating here which errors are fatal and which are not is therefore pointless.
Being able to only handle the error conditions that you can reasonably expect, and ignore the others, is the whole purpose of providing exception handling in the first place. Having the whole PHP OO API return false for every error without giving the nature of the error defeats this purpose entirely.
Therefore, IMO, proper implementation of exception handling should at least provide exception functionality for the entire OO API, and maybe even for the procedural API as well, as they're not interchangeable, meaning OO apps will use the procedural API as well.
I'm well aware that this is not going to happen, so maybe a compromise would be possible. Perhaps a zval type IS_ERROR that evaluates to FALSE for most common purposes, but can be used to identify the actual error condition that occurred, or the ability to pass more context to a user-defined error handler could be considered ?
And for the E_WARNINGs, maybe a built-in Exception specialization (ie. NonFatalException) that is ignored by the top level catch() ?
-- Ard
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
