Hi! > I am surely missing use cases because I wonder why we need @, at all?
Many functions have to deal with "dirty" data - e.g. loading a file that is supposed to be JSON but may be in fact be invalid in any of the hundreds ways. In some cases, we want full diagnostics, in other cases, just knowing it's a bad file is enough, and any messages are a waste of time in the best case, and invitation to DoS in the worst. If it'd invalid, we drop it and ignore it and don't want to hear anymore about it. Of course, it's possible to make special validation function to be run before actual parsing, but the obvious performance and stability issues with this make it far inferior solution to just use actual parser and suppress all diagnostics that could possibly come from it. > Yes there are functions generating extra messages and should not, be fro. > PHP implementation or from external libraries (wrapping stderr to php > errors). All of them could be fixed. In theory, yes. In practice, no, it's not happening anytime soon - we won't get rid of all warnings in all extensions that may not be needed. Thus, right now and in foreseeable future, using @ in this cases would be the easiest method. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
