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
variables.
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4427 (20090915) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4427 (20090915
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 acceptable, or recommended practice.
PHP 5.3
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
In PHP, there's rarely a 'best' way to do anything - that's the beauty of PHP!
Many ways to do things!
The example Nathan has given you is a indeed a correct way of dealing with the
notice message you had.
An alternative is:
$value = (isset($_GET['foo'])) ? $_GET['foo'] : null;
Same effect,
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
Happened across this thread and thought I'd give an update on progress
on the New Zealand Post API. To be honest things have been moving much
slower than I expected after we rushed the example google gadget and
rough API out the door (which were intended to help explain the
concept to key people
not to listen to those we're trying to
enable.
cheers,
Rob
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4427 (20090915) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--~--~-~--~~~---~--~~
NZ
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
I disagree with your solution Craig.
As you have said, the @ merely suppresses the error - it does nothing to clean
your code, nor does it make your code conform to any PHP standards.
Rather than bury the problem, why not fix it - and improve your coding standard
at the same time?
~ C
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
(
Yeah, -1 for error suppression.
Also,
$value = isset($_GET[q]) ? $_get['q'] : null;
is about 20% quicker than
$value = @$_GET[q];
That's several tenths of one microsecond you can save with each
operation :P
Regards,
Hamish
On Sep 16, 3:09 pm, Cliff Black cl...@kiffy.net wrote:
I
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)
Catch your errors, Debug Debug Debug profit.
~ C
-Original Message-
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
20 matches
Mail list logo
