Should PEAR code emit notices/warnings?
| From: | Christian Schmidt | Date: | Tue, 11 Mar 2008 23:23:43 +0000 |
| Subject: | Should PEAR code emit notices/warnings? | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-49380@lists.php.net to get a copy of this message | ||
If a PEAR package calls a native PHP function that emits a notice/warning, should that error be silenced using @function() or similar?
Packages like Net_Socket and MDB2 silence all native errors and indicate error conditions only using PEAR_Error. Personally I prefer this approach, but Till thinks that people should rather turn display_errors off or use a lower error_reporting level:
http://pear.php.net/pepr/pepr-comments-show.php?id=527
In my eyes, native notices/warnings are an poor-mans replacement for exceptions. Like when using exceptions, the PEAR package code can "catch" the error and handle it without letting the calling code know about it.
Also, whether something is an important error that should be displayed/logged depends on the circumstances. For example, if DOMDocument::loadXML() fails due to malformed XML, it may be important if it used to parse a string that is always expected to be XML. But if it is used inside a function that checks whether a string is wellformed XML, isWellformedXML($s), failure is often expected and logging all failed calls propably isn't useful.
PEAR packages are generally required to signal errors by returning a PEAR_Error or throwing an exception. I think it is confusing if they may also signal errors by emitting notices/warnings, as long as they originate from native functions.
If people for some reason want to log all errors, they can use a custom error handler that ignores the error_reporting level and always logs the error.
I guess my preference is related to how we handle errors in the company I work for. We consider notices/warnings above the current error_reporting threshold an indication that something happened that shouldn't have, i.e. there is an error somewhere that somebody should look into. Purely informational logging about various events is done elsewhere.
We have our own custom error handler that logs all errors above the error_reporting threshold to a database. Fatal errors cannot be caught this way, so they are read from the Apache log and written to the same database. All errors are manually handled (is it dangerous, is it a bug, is it a dangerous flaw in the environment etc). Currently all logged errors are in fact errors, i.e. something that shouldn't have happened.
I'd like to hear other people's view on this. Even if your log file inspection routines are different than what is explained in the latter two paragraphs, I am interested in hearing your comment on my general question in the subject of this email.
Christian