.
To: nzphpug@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
Using @ does not mean you're not handling errors. And not using @ does
not mean you are handling errors.
Consider this:
$something = @$_GET['something'];
if ( !$something )
{
// do something
}
// more validation on $something
Huh?
The situation is the same, a single typo (too when it should have been
foo), such as:
$value = (isset($_GET['too'])) ? $_GET['foo'] : null;
or:
$value = @$_GET['too'];
has exactly the same effect. There is no warning message that you
made the typo, and $value is always null.
-Craig
] Re: PHP 5.3.0 error
Using @ does not mean you're not handling errors. And not using @ does
not mean you are handling errors.
Consider this:
$something = @$_GET['something'];
if ( !$something )
{
// do something
}
// more validation on $something here ...
Another
Hi,
Certainly an alternative way to write clean code is to use symfony or
simply to always use your own function to hide the ugliness of this:
function getArrayElem($ary, $elm, $def=null) {
return (isset($ary[$elm])) ? $ary[$elm] : $def;
}
Of course if you use
The problem with ignoring E_NOTICE is also that once you got 500 of them
coming up if turned on, its hardly possible to find a typo.
Therefore it may look cumbersome, but is necessary to use isset everywhere
to keep in control of debug time.
Kind regards,
Jochen
Mobile: 021 567 853
Phone: 09
Hi.
No it's not the same effect. The second line hides the typo, the first
exposes the error when $_GET['foo'] is not set.
'too'' is a typo, it's highly unlikely that it would just happen to be
another element that did exist. There's no notice about 'foo' because
that part of the expression
same way as having the same typo when using symphony
and when using symfony :P
On Thu, Sep 17, 2009 at 8:43 AM, craiganz crai...@orangecat.co.nz wrote:
Hi.
No it's not the same effect. The second line hides the typo, the first
exposes the error when $_GET['foo'] is not set.
'too'' is a
Hi.
I'll try to be more clear. I've already posted a similar function and
i didn't use @ :-)
Symfony uses the construct:
@$ary[$elm];
within it's code -- you may or may not make use of the methods that
use it. I wasn't trying to suggest @ would be used if you called
getParameter.
Most of
Symfony doesn't use @ for retrieving get/post parameter, but uses it
for database connection and other connection type as well as object
chaining, but all these suppress errors are handled/caught somewhere
else (e.g.:write them to log or throw them to browser on dev mode).
On Thu, Sep 17, 2009
On Sep 17, 8:43 am, craiganz crai...@orangecat.co.nz wrote:
Hi.
No it's not the same effect. The second line hides the typo, the first
exposes the error when $_GET['foo'] is not set.
'too'' is a typo, it's highly unlikely that it would just happen to be
another element that did exist.
a ternary - both have exactly the
same effect.
~ C
-Original Message-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf Of
Sid Bachtiar
Sent: Thursday, 17 September 2009 9:26 a.m.
To: nzphpug@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
Symfony doesn't use
@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
You beat me to it Sid :)
Symfony definitely doesn't use the @ suppression operator.
The method appears in a lot of classes - sfRequest, sfDatabase, but they all
are just shortcuts for $sfParameterHolder-get().
Here's the source
(File
They also use:
@$array['element']
Which was my point, not that it was used in getParameter itself.
On Sep 17, 10:25 am, Cliff Black cl...@kiffy.net wrote:
Interestingly enough, I've been browsing the source of Symfony some more and
found even they can't decide which is better:
Of
Cliff Black
Sent: Thursday, 17 September 2009 9:42 a.m.
To: nzphpug@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
You beat me to it Sid :)
Symfony definitely doesn't use the @ suppression operator.
The method appears in a lot of classes - sfRequest, sfDatabase, but they all
Sid Bachtiar wrote:
I think isset is better used when reading $_GET since there should not
be null but array_key_exists is better for later in different level
when the application can actually set null to request object.
And why shouldn't a project use both isset and array_key_exists? :)
Hi Michael,
Try to replace
$errno,$errstr
with
$errno,$errstr
Michael:
Hello all,
This error is showing in PHP 5.3.0 - the code worked in PHP 5.2.10.
Deprecated: Call-time pass-by-reference has been deprecated in [deleted] on
line 87 Deprecated: Call-time pass-by-reference has
://control.kennedytechnology.com
-Original Message-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf
Of Michael
Sent: Wednesday, 16 September 2009 12:03 p.m.
To: nzphpug@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
On Wed, 16 Sep 2009 10:49:50 Dmitry Ruban wrote:
Hi
-Original Message-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf Of
Michael
Sent: Wednesday, 16 September 2009 1:14 p.m.
To: nzphpug@googlegroups.com
Subject: [phpug] Re: PHP 5.3.0 error
On Wed, 16 Sep 2009 13:02:38 Nathan Kennedy wrote:
Ok, no worries.
What
They are moving PHP to a more strict language, and this is a very good
thing.
With PHP you can write code like:
$array = array('name'='Stig', 'email'='s...@sdm.co.nz');
echo $array['telephone'];
Here PHP 5 will allow this and show no warnings, even though the
'telephone' key was never
On Wed, 16 Sep 2009 13:18:58 Cliff Black wrote:
It's standard practice to define/check variables or array keys for
existence before testing or calling them - in any language. The fact that
PHP has 'let you away with it' by removing the NOTICE or WARNING error
reports doesn't mean it's been
: [phpug] Re: PHP 5.3.0 error
On Wed, 16 Sep 2009 13:18:58 Cliff Black wrote:
It's standard practice to define/check variables or array keys for
existence before testing or calling them - in any language. The fact that
PHP has 'let you away with it' by removing the NOTICE or WARNING error
Michael wrote:
On Wed, 16 Sep 2009 13:02:38 Nathan Kennedy wrote:
Then you might want to try something like:
$value = array_key_exists('retry',$_GET)?$_GET['retry']:null;
Which will not return that notice.
The question is WTH were they thinking?
PHP 5.3.0 seems to break quite a few
Michael wrote:
As for books, there are a great deal of books out there that are
teaching terrible procedural PHP code. I happened to read a textbook
used by a large University here in melbourne, MySQL queries had no
'real_escape_string', $_GET variables were echoed directly to page with
no
On Sep 16, 1:02 pm, Nathan Kennedy nat...@kennedytechnology.com
wrote:
$value = array_key_exists('retry',$_GET)?$_GET['retry']:null;
A much simpler solution is to use @:
$value = @$_GET['retry'];
Which produces exactly the same result as above, but suppresses all
warning/notice messages. The
-Original Message-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf Of
craiganz
Sent: Wednesday, 16 September 2009 3:00 p.m.
To: NZ PHP Users Group
Subject: [phpug] Re: PHP 5.3.0 error
On Sep 16, 1:02 pm, Nathan Kennedy nat...@kennedytechnology.com
wrote:
$value
Hi.
I'm not suggesting one use @ as a blanket solution, but in this case
it's simply a shorthand way of saying that you understand that the
array element might not exist (and that is OK).
The choice is:
@$var
or
( array_key_exists('retry',$_GET) )? $var: null
The problem with the second
Hi.
Actually this type of construct even masks the same type of error it's
trying to prevent.
Consider this programming error:
$value = (isset($_GET['too'])) ? $_GET['foo'] : null;
-Craig
PS, my previous post should really have been:
The choice is:
@$_GET['retry']
or
(
-Original Message-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf Of
craiganz
Sent: Wednesday, 16 September 2009 3:00 p.m.
To: NZ PHP Users Group
Subject: [phpug] Re: PHP 5.3.0 error
On Sep 16, 1:02 pm, Nathan Kennedy nat...@kennedytechnology.com
wrote:
$value
-
From: nzphpug@googlegroups.com [mailto:nzph...@googlegroups.com] On Behalf Of
craiganz
Sent: Wednesday, 16 September 2009 4:06 p.m.
To: NZ PHP Users Group
Subject: [phpug] Re: PHP 5.3.0 error
Hi.
Actually this type of construct even masks the same type of error it's
trying to prevent.
Consider
On Wed, 16 Sep 2009 16:08:36 Cliff Black wrote:
Once again, I disagree.
Catching of errors and dealing to them is critical to developing any
application. Simply ignoring or suppressing issues is not only amateur,
it's potentially going to create flaky products.
Being lazy and ignoring the
On Sep 16, 4:14 pm, Cliff Black cl...@kiffy.net wrote:
Are you serious?
A mistype does not constitute a programming error.
That's like saying I meant to enter preg() but instead I typed ereg()
We've all done it... lots! (and I know I'll do it lots more too! Haha)
Ha, didn't catch the
Using @ does not mean you're not handling errors. And not using @ does
not mean you are handling errors.
Consider this:
$something = @$_GET['something'];
if ( !$something )
{
// do something
}
// more validation on $something here ...
Another example:
Sid
I agree, after all first you have to decide is $_GET['something'] not
set an error?
And that is defined in the context of the application / design /coding
standards
Neven
Using @ does not mean you're not handling errors. And not using @ does
not mean you are handling errors.
Consider
33 matches
Mail list logo
