|
Hello,
I was browsing through the ZF source when I noticed a couple of lines in Zend_Filter.php: line 323: $status = @preg_match('... line 340: $status = @preg_match('... AFAIK none of the PCRE functions issue warnings, so using the '@' will not accomplish anything useful here ... it will only make it harder to detect real errors. Does anyone else feel the use of '@' in conjunction with preg_*() functions should be avoided in the framework? regards, Peter regards, Peter Send instant messages to your online friends http://au.messenger.yahoo.com |
|
> Does anyone else feel the use of '@' in conjunction with preg_*()
> functions should be avoided in the framework? My opinion : I would say that @ should be prevented almost everywhere... We should have other ways to handle errors and warnings than supressing/ignoring them. Greetings Thomas |
|
In reply to this post by Peter Hodge-5
My 2c, @ should be avoided unless there is clearly a very good reason. Otherwise we'll not receive those informative errors, and be waylaid in a debugger trying to figure it out. Using @ with preg_* seems odd. Suppression of missing param errors for some reason, maybe? Pádraic Brady http://blog.quantum-star.com http://www.patternsforphp.com ----- Original Message ---- From: Thomas Weidner <[hidden email]> To: [hidden email]; [hidden email] Sent: Wednesday, October 4, 2006 8:19:33 AM Subject: Re: [fw-general] Questionable use of '@' error suppression on preg_match() > Does anyone else feel the use of '@' in conjunction with preg_*() > functions should be avoided in the framework? My opinion : I would say that @ should be prevented almost everywhere... We should have other ways to handle errors and warnings than supressing/ignoring them. Greetings Thomas |
|
AFAICR this was done because Zend_Input_ has the potential to operate on multidimensional arrays - this is a simple (but not very graceful) way of handling instances where the value is an array rather than a string value. @ should be avoided unless there is clearly a very good reason. Otherwise we'll not receive those informative errors, and be waylaid in a debugger trying to figure it out. Using @ with preg_* seems odd. Suppression of missing param errors for some reason, maybe? -- Simon Mundy | Director | PEPTOLAB """ " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" " 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 |
|
Should that not be prevented with an is_array() check instead of using an @? Using the @ sounds quite dirty to me. ;)
On 10/4/06, Simon Mundy <[hidden email]> wrote:
-- Stefan Koopmanschap http://www.stefankoopmanschap.nl/ http://www.leftontheweb.com/ |
|
Stefan, I agree. Everything should be E_STRICT, suppression of errors is
not in the ZF dictionary :-). Regards, Andries Seutens Belgium http://andries.systray.be Stefan Koopmanschap schreef: > Should that not be prevented with an is_array() check instead of using > an @? Using the @ sounds quite dirty to me. ;) > > On 10/4/06, *Simon Mundy* < [hidden email] > <mailto:[hidden email]>> wrote: > > AFAICR this was done because Zend_Input_ has the potential to > operate on multidimensional arrays - this is a simple (but not > very graceful) way of handling instances where the value is an > array rather than a string value. > >> @ should be avoided unless there is clearly a very good reason. >> Otherwise we'll not receive those informative errors, and be >> waylaid in a debugger trying to figure it out. Using @ with >> preg_* seems odd. Suppression of missing param errors for some >> reason, maybe? > > -- > > Simon Mundy | Director | PEPTOLAB > > """ " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" " > 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 > Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 > 9654 4124 > http://www.peptolab.com > > > > > > -- > Stefan Koopmanschap > http://www.stefankoopmanschap.nl/ > http://www.leftontheweb.com/ <http://www.leftontheweb.com/> > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.407 / Virus Database: 268.12.12/462 - Release Date: 3/10/2006 > |
| Powered by Nabble | Edit this page |
