Dan Ackroyd wrote on 06/01/2016 17:12:
Work on a plan on how to migrate all internal errors/warnings to individual exceptions. The current way of using set_error_handler to convert warnings/errors into generic exceptions isn't good enough.
Again, you're focussing exclusively on that sub-set of warnings which are actually errors in disguise.
I think it would be perfectly reasonable to implement a new file handling API, which behaves like modern PHP (objects, exceptions, etc) rather than being a thin wrapper for C (which is why fopen() does what it does). There'd then be no particular need to "suppress" any exceptions thrown from that, because if the handle is invalid, you actually need to do something different in the catch clause. In the current C-based API, the "catch" is the "if ( $fh === false )"; the warning is actually superfluous, hence the desire to suppress it.
But this doesn't actually present a solution to the dozens of other warnings and notices. It doesn't do anything to help Stas's example for instance:
@$counts[$item]++; This is not something which should ever throw an exception, however easy that exception was to discard. On the other hand, the "suppress" operator might be usable in conjunction with categorised warnings; e.g. $counts[$item]++ suppress ET_ARRAY_NOSUCHKEY; I would also contend that a correctly thrown exception should never be something you want to just suppress - at the very least, you want to log it, and probably you want to skip or add some logic. For instance, this makes no sense to me: $db = new PDO($dsn) suppress PDO_Exception; // oops, now I have to check if $db instanceof PDO, rather than just jumping to catch/finally @ doesn't suppress exceptions, nor does it stop fatal errors being fatal; nor should its replacement. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
