Quantcast

Questionable use of '@' error suppression on preg_match()

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Questionable use of '@' error suppression on preg_match()

Peter Hodge-5
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 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Questionable use of '@' error suppression on preg_match()

Thomas Weidner
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Questionable use of '@' error suppression on preg_match()

padraicb
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Questionable use of '@' error suppression on preg_match()

Simon Mundy
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Questionable use of '@' error suppression on preg_match()

Stefan Koopmanschap
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:
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
<a href="http://www.peptolab.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.peptolab.com





--
Stefan Koopmanschap
http://www.stefankoopmanschap.nl/
http://www.leftontheweb.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Questionable use of '@' error suppression on preg_match()

Andries Seutens
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
>  

Loading...