ZF2-13: Remove internal error handler on reading files

Description

Zend\Config* uses an error handler to check if reading of a file has been succeed.

This can be rewritten on hiding errors while reading/parsing the file using the "@" operator and on a returned false get the last error using error_get last.

(Since PHP 5.2.7 parse_ini_file also returns false on failure)

Comments

Also on errors reading xml data the libXMLError can be used and for each error an exception can be thrown by using previous argument.

Our coding standard frowns on usage of error suppression; it's an expensive operation, and also not friendly with automated tools and debuggers (e.g., ext/scream will cause load failure, and PHPUnit throws errors when suppression occurs that are often hard to trace).

I agree that we should update how parse_ini_file is handled on failure, and, per your initial pull request, SimpleXML; however, error suppression should not be part of the solution.

Hi Matthew,

I'm not 100% the same opinion because of: - using of a temporarily error handler its a little bit slower than using error suppression with "@" and a little bit more slower if no error was reported (see attachment) - using of a temporarily error handler its also a way of error suppression but only another way to do that - PHPUnit doesn't report suppressed errors - using of "@" and throwing an Exception with the last error is more a rewrite of this error (Error -> Exception) as an real error suppression. Not ? - only ext/scream will break here but this extension is a very specific debugging tool which changes the code logic by disabling of "@" (I don't know other extensions/tools where this is an issue) - If we have to create an temporarily error handler on each PHP function which would create an error than we blow up the code extremely - I found 222 usages of "@" within the current library (^[a-z0-9_-\$\s\=]+@.+)

Over all I also don't like error suppression but using a temporary error handler is also a way of error suppression and on PHP there is sometimes no way not using it :( For me it should debate from case to case with some points like: - only use it on internal php functions - returns the function something to check if an error was triggered - do something on error (not only suppress it) - could the function trigger more than one error and if yes use a temporary error handler (or something similar) to report all triggered errors ...

added benchmark

fixed and merged to master 71a4519a64cf8017d912