Re: Don't silence fatal errors

On Thu, Feb 7, 2019 at 3:14 PM Christian Schneider <cschneid@cschneid.com> wrote: > > Am 07.02.2019 um 02:32 schrieb Pierre Joye <pierre.php@gmail.com>: > > On Thu, Feb 7, 2019, 8:07 AM Girgias <george.banyard@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