"Rowan Collins" wrote in message news:54e12349.7070...@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....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
