On Thu, Feb 7, 2019 at 3:14 PM Christian Schneider <cschn...@cschneid.com> wrote: > > Am 07.02.2019 um 02:32 schrieb Pierre Joye <pierre....@gmail.com>: > > On Thu, Feb 7, 2019, 8:07 AM Girgias <george.bany...@gmail.com wrote: > >> The most common case which comes to mind is to suppress erros while file > >> reading. > >> Because even if you check a file exists it could be deleted inbetween the > >> check and the > >> read command. As you can see this is even written in the documentation [1] > >> > >> [1] https://secure.php.net/manual/en/function.fopen.php > > > > That is one the cases I meant. Also this is a bug in the user code. I can > > imagine doing it on purpose for performance reasons (if the file is > > created/deleted by other apps) tho'. > > flock is what should be used here. > > Sorry if I'm missing something but would flock() help with > file_get_contents() and an external program deleting a file? > > We have the following fields where we sometimes use @ to suppress error_log > entries so they do not hide real problems not handled by our code already: > - filesystem operations like file_get_contents() or mkdir() which can have > (benevolent) races > - json_decode() of external data (we check the validity of the data > afterwards anyway) > - DB connections which we log more detailed separately where the generic > error is not interesting > > In general I agree with the notion of using @ as little as possible but I > think it will has use cases where using error_reporting() instead would > decrease code readability. > > Please do not remove @ ;-)
My thought that @ mainly relates to another RFC where errors/warning are very inconsistently reported or designed (like forcing one to use @). 8 would be a good candidate to clean that up, like the TypeError RFC. best, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
