Grzegorz Zdanowski wrote on 05/01/2016 12:27:
Before deprecating @ operator I think we should make a RFC which cover unified setting to convert all E_* to exceptions (like PhpWarningException). I know it's just a temporary solution, because exception should be more specific, but it's a huge amount of work to replace all errors and warnings with proper exceptions.
This is definitely not the solution. I've seen this suggested a few times over the years, and every time people seem to miss a vital point: Warnings are not, in general, a fatal situation. A useful rule of thumb I heard for "should I throw an exception?" is "would I be happy to use a die() statement?"
Even if you don't accept that, the main purpose of an exception is to force the code down a different path. (I've seen lots of discussions about exceptions being great because they have stack traces, but have never understood why any other mechanism couldn't also have those).
In a few places, like the file-handle API, the Warning is accompanied by an invalid return value (usually false) and probably should be an exception - the code will definitely need to follow a different path, and dying would often be better than proceeding with an invalid handle (which will probably end up fatal later).
But in many cases, an E_WARNING (or an E_NOTICE) really is just a warning - most code *doesn't* want to go down an alternative path, but it might want to log a message. In a few cases, code does want to go down a different path, and currently has to use the "error handler" infrastructure. In other cases, code wants to never log the message, and currently has to use the @ operator.
The main problem, in my opinion, with the current system of "errors" (better called "messages") is that they provide only two pieces of identifying information: an integer representing severity, from a small list; and a string which may have placeholders, may change between versions, and does not come from a documented list. This means you can say "suppress everything with E_NOTICE severity" but not "suppress all array-assignment warnings"; and you can set up an error handler to convert everything into exceptions, but a handler to convert all file-handle warnings into exceptions would have to pattern-match every message string to identify them.
The only way out of this that I can see is to replace the current string-based internal message APIs with something that forces the extension developer to pre-define a set of codes, and provide the substitution parameters for the error directly. This could then allow more information to be exposed to userland, and more granular stacking of handlers and configuration to mask off different types based on their codes.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
