Re: Re: Should PEAR code emit notices/warnings?

Michael Gauthier wrote: > On Tue, 2008-11-03 at 19:23 -0500, Gregory Beaver wrote: > >> Christian Schmidt wrote: >> >>> 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 >>> >> <snip> >> >> Till is incorrect, coding standards forbid PEAR packages from warnings >> or notices, regardless of their source. >> > > Till has a point about error suppression though. I've run into a problem > in PEAR before where error suppression was used on a conditional > include. The returned PEAR_Error object had a message about the driver > class not being found. It took me forever to determine that the driver > was being found and just had a parse error. This is completely different: there is no reason to suppress all possible errors within an entire file, but inside an internal function that is known to throw irrelevant warnings (for instance, fopen() on an http stream if there is a connection issue) which should instead be packaged into exceptions, this is a big issue. Why? We tell our users there is only one source of errors from a PEAR package, which is either PEAR_Error or PEAR_Exception, depending on the targeted PHP version. Once we introduce spurious and useless warnings, this makes using the package a lot less friendly. Driver loading can be handled in a much friendlier manner. First, using fopen() with the 3rd optional include_path parameter to locate the file, and throwing an error if it doesn't exist. parse errors should never be suppressed - remember, we are talking about *warnings* and *notices* which are never fatal - ever. Greg