Re: [RFC] Exceptions in the engine

"Rowan Collins" wrote in message news:54E12349.7070806@gmail.com...

On 14/02/2015 00:09, Yasuo Ohgaki wrote:

Hi Nikita, On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

As such I'm re-proposing this RFC for inclusion in PHP 7:

     https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design.

Are E_WARNING, etc future scope? I briefly looked the patch. It seems it covers only engine errors. I suppose it's the scope of this RFC, though. If API is made adoptable to modules for E_WARNING, etc, it would be great.

Much though I'd love a more OO-approach to warnings, exceptions are not an appropriate mechanism for that. A rule of thumb I rather like is that you should only throw an exception in a case where your best alternative, if it is not handled, is to call die(). Clearly, E_ERROR meets this standard, and E_WARNING does not. There has been much talk previously that "exceptions are great because they include full backtraces", but there's no reason a new type of warning object couldn't also include those, while retaining the key characteristic of the default behaviour being to carry on with some fallback value (an empty loop, a null variable, etc) rather than to die('Uncaught Warning Exception!'). Regards,

This RFC only mentions errors with object methods, so what impact would it have with procedural functions. For example, if fopen('nonexistantfile.txt') fails the return value is FALSE and an E_WARNING is generated, but it is difficult to trap the error message (it could be a permissions error, for example). Is there any plan to convert procedural functions to throw exceptions? -- Tony Marston