notice and warning

I turned on errors in php:

ini_set('display_errors','1');

And I got a slew of notices and a couple of warnings.

The notices are mostly missing indexes from doing things like this:

$some_var = $_REQUEST['some_name'];

And the warnings are when I have something like this:

Missing argument 1 ...

function someFoo($var1){
if($var1){...}
}

someFoo();

So, I turned display_errors back off, but wonder if I should do
anything about the this.

What is good programming practice?

Generally I care more about whether a variable is null or empty, and
not whether it has been set, which is what the "notices" seem to be
about. If I were to do this:

if(isset($var1)){

// I'd still have to do this:

if($var1){...

PHP is a new language for me, and I'd like to write "correctly"...but
I don't want to bloat the code either.

Oh, one more thing, I slipped into perl mode and did this:
$SOME_ARRAY{some_key} and got no complaints, Is that "kosher"?

Jeff

Jeff wrote:

Quote:

>
I turned on errors in php:
>
ini_set('display_errors','1');
>
And I got a slew of notices and a couple of warnings.
>
The notices are mostly missing indexes from doing things like this:
>
$some_var = $_REQUEST['some_name'];
>
And the warnings are when I have something like this:
>
Missing argument 1 ...
>
function someFoo($var1){
if($var1){...}
}
>
someFoo();
>
So, I turned display_errors back off, but wonder if I should do
anything about the this.
>
What is good programming practice?
>
Generally I care more about whether a variable is null or empty, and
not whether it has been set, which is what the "notices" seem to be
about. If I were to do this:
>
if(isset($var1)){
>
// I'd still have to do this:
>
if($var1){...
>
PHP is a new language for me, and I'd like to write "correctly"...but I
don't want to bloat the code either.
>
Oh, one more thing, I slipped into perl mode and did this:
$SOME_ARRAY{some_key} and got no complaints, Is that "kosher"?
>
Jeff
>
>

I always run with notices on on my development system, and fix the
problems which are called out.

They aren't necessarily errors - but the are potential bugs.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jeff schreef:

Quote:

>

Hi Jeff,

Quote:

I turned on errors in php:
>
ini_set('display_errors','1');

Good.

Quote:

>
And I got a slew of notices and a couple of warnings.
>
The notices are mostly missing indexes from doing things like this:
>
$some_var = $_REQUEST['some_name'];
>

Don't use $_REQUEST[].
Use $_POST or $_GET or $_COOKIE or whatever you need, but don't use
$_REQUEST.
Doing so means you don't know where your data comes from.
(Some people, like me, think it should never have been added to the
language.)

Quote:

And the warnings are when I have something like this:
>
Missing argument 1 ...
>
function someFoo($var1){
if($var1){...}
}

Don't call functions with the wrong number of arguments. ;-)

Quote:

>
someFoo();
>
So, I turned display_errors back off, but wonder if I should do
anything about the this.

Yes you should.
Always have all notices/warnings on during development, and display them.

Quote:

>
What is good programming practice?

I think the best practise is:
1) Develop with all warnings/notices on.
2) Fix them
3) Test a lot. Try to hack your own application. Do things like sending
bad formdata (eg missing values, wrong values, etc.)
4) fix it.

When you have a good feeling and open your application to the world:
5) Do NOT display errors/warnings/etc anymore, but LOG them.
(Seeing errors makes it very easy for a hacker to gain more ground.)
6) Check your errorlog a lot.

In some of mine 'more serious' applications, I do the following:
- I make my own errorhandler.
- On any error (notice/warning/etc) I log this error, and send an email
to myself warning me about it.
- When an error accors, I simply redirect to a page saying: "Sorry, we
encountered an error, which is logged. Sorry for any inconvenience", or
something like that.

That way I make sure I never leak information of the internals of the
application (by setting display_error to off), but I get to see the
errors my application makes very quickly because of the email to myself.

Read more here:
http://nl2.php.net/manual/en/ref.errorfunc.php

Quote:

>
Generally I care more about whether a variable is null or empty, and
not whether it has been set, which is what the "notices" seem to be
about. If I were to do this:
>
if(isset($var1)){
>
// I'd still have to do this:
>
if($var1){...

I don't know how you program, but I never find myself in that situation.
I initialize all variables I use, and always call functions with the
right number of arguments.
That is not 'bloated code', but clean programming.

Quote:

>
PHP is a new language for me, and I'd like to write "correctly"...but I
don't want to bloat the code either.
>
Oh, one more thing, I slipped into perl mode and did this:
$SOME_ARRAY{some_key} and got no complaints, Is that "kosher"?

You mean {} instead of []?
Never saw it, never used it. Isn't that an error?

Quote:

>
Jeff
>

Good luck!

Regards,
Erwin Moller

Erwin Moller wrote:

Quote:

Jeff schreef:

Quote:

>>

>
Hi Jeff,
>
>
>

Quote:

> I turned on errors in php:
>>
>ini_set('display_errors','1');

>
Good.
>

Quote:

>>
> And I got a slew of notices and a couple of warnings.
>>
> The notices are mostly missing indexes from doing things like this:
>>
>$some_var = $_REQUEST['some_name'];
>>

>
Don't use $_REQUEST[].
Use $_POST or $_GET or $_COOKIE or whatever you need, but don't use
$_REQUEST.
Doing so means you don't know where your data comes from.
(Some people, like me, think it should never have been added to the
language.)
>
>

Quote:

> And the warnings are when I have something like this:
>>
>Missing argument 1 ...
>>
>function someFoo($var1){
>if($var1){...}
>}

>
Don't call functions with the wrong number of arguments. ;-)
>
>

Quote:

>>
>someFoo();
>>
> So, I turned display_errors back off, but wonder if I should do
>anything about the this.

>
Yes you should.
Always have all notices/warnings on during development, and display them.
>
>

Quote:

>>
> What is good programming practice?

>
I think the best practise is:
1) Develop with all warnings/notices on.
2) Fix them

Thanks Erwin & Jerry, I think then that I should "fix" notices for best
practice?

Now, lets say I have this notice ridden bit...

public function __construct($D){
global $DEFAULTS;
$this->template = $D['template']; // prefer template stored in data

if(! $this->template){$this->template = $_GET['template'];} //
otherwise use the one passed in on the query string

if(! $this->template){$this->template = $DEFAULTS['default_template'];}
// if still no template, use the default

would this be preferred:

if(isset($DEFAULTS['default_template'])){$this->template =
$DEFAULTS['default_template'];}

if(isset($_GET['template'])){$this->template = $_GET['template'];}

if(isset($D['template'])){$this->template = $D['template'];}

That would do the same thing except it wouldn't test for null or empty.

I'm used to Perl and perl does not care if a variable has been set,
I'm also used to doing this shorthand: $some_val ||= $some_default;

It looks to me that the php mindset is different than perl and I
haven't quite wrapped my mind about it.

Jeff

Quote:

3) Test a lot. Try to hack your own application. Do things like sending
bad formdata (eg missing values, wrong values, etc.)
4) fix it.
>
When you have a good feeling and open your application to the world:
5) Do NOT display errors/warnings/etc anymore, but LOG them.
(Seeing errors makes it very easy for a hacker to gain more ground.)
6) Check your errorlog a lot.
>
In some of mine 'more serious' applications, I do the following:
- I make my own errorhandler.
- On any error (notice/warning/etc) I log this error, and send an email
to myself warning me about it.
- When an error accors, I simply redirect to a page saying: "Sorry, we
encountered an error, which is logged. Sorry for any inconvenience", or
something like that.
>
That way I make sure I never leak information of the internals of the
application (by setting display_error to off), but I get to see the
errors my application makes very quickly because of the email to myself.
>
Read more here:
http://nl2.php.net/manual/en/ref.errorfunc.php
>
>

Quote:

>>
> Generally I care more about whether a variable is null or empty, and
>not whether it has been set, which is what the "notices" seem to be
>about. If I were to do this:
>>
> if(isset($var1)){
>>
>// I'd still have to do this:
>>
>if($var1){...

>
I don't know how you program, but I never find myself in that situation.
I initialize all variables I use, and always call functions with the
right number of arguments.
That is not 'bloated code', but clean programming.
>

Quote:

>>
> PHP is a new language for me, and I'd like to write "correctly"...but
>I don't want to bloat the code either.
>>
>Oh, one more thing, I slipped into perl mode and did this:
>$SOME_ARRAY{some_key} and got no complaints, Is that "kosher"?

>
You mean {} instead of []?
Never saw it, never used it. Isn't that an error?
>

Quote:

>>
> Jeff
>>

>
Good luck!
>
Regards,
Erwin Moller

..oO(Jeff)

Quote:

>Now, lets say I have this notice ridden bit...
>
>public function __construct($D){
>global $DEFAULTS;
> $this->template = $D['template']; // prefer template stored in data
>
> if(! $this->template){$this->template = $_GET['template'];} //
>otherwise use the one passed in on the query string

What do you actually want to test for? An unset template? Empty
template? A template with the string '0'?

You should always exactly write what you want to test for and don't rely
too much on PHP's type juggling. The '!' is a logical operator and
should not be used to check if a string or an array is empty. In this
case empty() is the better choice.

if (empty($D['template'])) {
if (empty($_GET['template'])) {
$this->template = $DEFAULTS['default_template'];
} else {
$this->template = $_GET['template'];
}
} else {
$this->template = $D['template'];
}

Or the same with ternary operators:

$this->template = empty($D['template'])
? empty($_GET['template'])
? $DEFAULTS['default_template']
: empty($_GET['template'])
: $D['template'];

Of course you would also have to validate/sanitize the GET value before
you use it. Never trust any user-submitted data.

Micha

..oO(Jeff)

Quote:

So, I turned display_errors back off, but wonder if I should do
>anything about the this.
>
What is good programming practice?

_Always_ develop with error_reporting set to highest level (preferrably
E_ALL|E_STRICT) and fix all E_NOTICE errors. Even if it's just a notice,
it might be the reason for a real bug:

$someNiceVar = TRUE;
....
if ($someNicevar) {
...
}

It's just a little typo. But with notices disabled you would have a hard
time to find such bugs.

Quote:

Generally I care more about whether a variable is null or empty, and
>not whether it has been set, which is what the "notices" seem to be
>about. If I were to do this:
>
if(isset($var1)){

empty() exists.

Quote:

>// I'd still have to do this:
>
>if($var1){...

This should only be used if $var is a boolean.

Quote:

PHP is a new language for me, and I'd like to write "correctly"...but
>I don't want to bloat the code either.

Error handling is no bloat. But without it your code may _blow_.

Quote:

>Oh, one more thing, I slipped into perl mode and did this:
>$SOME_ARRAY{some_key} and got no complaints, Is that "kosher"?

No. I didn't even know this was possible, because AFAIK it's not
documented. It might work because in older PHP {} was also used to
access single characters in a string like elements in an array. But this
is deprecated in favour of [].

Micha

<snip>

Quote:

>In some unrelated part of your app you decide to store a userid in the
>$_SESSION so you have it easy at hand on some other pages. The userid
>contains the userid of the currently logged in user.
>>
>Now you find yourself in the situation that when you call this script for
>any reason without the POST info, you will delete yourself if you prefer
>$_REQUEST over $_POST.

well, in my case, for my users i validate the user name, password, initial
security code they supplied, and the security code it should match. that is
stored in a session. every 'secured' page they access hits my user table for
a record where the user name and password exist. i may well return the user
id from that query, but, by the time the script (userdelete.php or whatever)
comes into play, i've already created an instance of a 'user' class. i
ensure the userid from post/get/cookie never comes into play by unsetting
those named variables that overlap...futher, you assume i allow them to
overlap in the first place. my users are not 'users', they are 'people'. a
person can be a user, but it's not both ways. editing a user means i'll
$_REQUEST['person*']...where the asterisk is Id, Name, Email, etc...my
'user' variables that are passed only pertain the the currently logged on
user. and, i don't allow users to delete themselves. :)

Dale schreef:

Quote:

Quote:

>>In some unrelated part of your app you decide to store a userid in the
>>$_SESSION so you have it easy at hand on some other pages. The userid
>>contains the userid of the currently logged in user.
>>>
>>Now you find yourself in the situation that when you call this script for
>>any reason without the POST info, you will delete yourself if you prefer
>>$_REQUEST over $_POST.

>
well, in my case, for my users i validate the user name, password, initial
security code they supplied, and the security code it should match. that is
stored in a session. every 'secured' page they access hits my user table for
a record where the user name and password exist.

What?
You don't ask your already logged-in users for their username/password
for every page they visit I hope?
Of course you store that in a session after authentication.

i may well return the user

Quote:

id from that query, but, by the time the script (userdelete.php or whatever)
comes into play, i've already created an instance of a 'user' class. i
ensure the userid from post/get/cookie never comes into play by unsetting
those named variables that overlap...

Don't you see you are solving problems created by yourself?
Let me say this very clearly: IF YOU PROGRAM BETTER YOU HAVE NO PROBLEMS
WITH SAME HASHKEY IN SUPERGLOBALS.
No need to 'unset' whatever it is you are unsetting.

futher, you assume i allow them to

Quote:

overlap in the first place.

No, it is quit clear to me you should avoid that at any costs if you
want to deliver a working application.
The problem is you fail to see that YOU and your precious friend
$_REQUEST created this problem, not PHP.

my users are not 'users', they are 'people'. a

Quote:

person can be a user, but it's not both ways. editing a user means i'll
$_REQUEST['person*']...where the asterisk is Id, Name, Email, etc...my
'user' variables that are passed only pertain the the currently logged on
user. and, i don't allow users to delete themselves. :)

I fail to see the relevance of the above statement.
You explain how your program works, which is of little relevance to the
REQUEST/apropriate_superglobal discussion.

Regards,
Erwin Moller

"Michael Fesser" <netizen@gmx.dewrote in message
news:rtpg845c4lufs27lgkiic1domqbea7pqlu@4ax.com...

Quote:

.oO(Dale)
>

Quote:

>>"Erwin Moller"
>><Since_humans_read_this_I_am_spammed_too_much@sp amyourself.comwrote in
>>message news:488760ea$0$49891$e4fe514c@news.xs4all.nl...

Quote:

>>>
>>Are you the same as Barry by the way?

>>
>>yes...i'm playing with jerry stuckle. he likes to plonk people who
>>disagree
>>with him. i'm trying to fill up his filter(s). :)

>
This is childish.
>

Quote:

>>one of my points was about scaling. the one script may best have it's
>>functionality included somewhere else. for your sake, say you have a
>>script
>>called users.php. that script lists, edits, deletes users. it may 'get' an
>>input to delete something, at which point, it would want to include_once
>>deleteuser.php. since deleteuser.php expects a 'post' for the id of the
>>user
>>to delete, the action won't be performed - no deletion. if i have
>>edituser.php that expects 'get' inputs, it would be able to successfully
>>edit a user.
>>
>>if i want to reuse deleteuser.php, i either have to make it accept 'get'
>>inputs and thereby change my previously 'magic' business rules, or, i'd
>>have
>>to change users.php to either now expect 'post' instead of 'get', or force
>>it to copy the 'get' vars to 'post' vars so that all three scripts would
>>work (users.php, edituser.php, deleteuser.php).

>
That's just a broken design. It seems that you haven't understood the
differences between POST and GET and when you should use one or the
other.
>
In short: Listing should done with GET, changing with POST. Simple and
reliable.
>

Quote:

>>And what 'bad design'?
>>Are you claiming using $_REQUEST instead of $_POST/$_GET/whatever, is
>>BETTER design? You can't be serious.

>>
>>i'm saying that *how* your input arrives is irrelevant to how your system
>>operates. relying on data coming from one venue (POST) to mean something
>>completely different from another (GET) is an exercise in bad design.

>
POST and GET _do_ have a totally different meaning, otherwise we would
not have these various methods at all. There are important differences
between them on the HTTP level and how user agents handle them.
>
BTW: How do you handle file uploads? Technically they're also just some
input data, but can't be found in $_REQUEST. Doesn't this violate your
world view of "good design"?

i was very careful to say that there are cases where you'd want to use a
specific sg, file uploads is not the only case. i gave another example as
well, such as cli.

Quote:

>>my claim is that BETTER design is removing the importance or related
>>meaning
>>to the venue(s) from which we expect input.

>
Better design takes exactly the data it expects from exactly the source
where it's supposed to come from.

the exact source, for me, is the end user. :)

<snip>

Quote:

_You_ are relying on some kind of magic when using $_REQUEST. Its
meaning is totally unclear and its structure depends on configuration
options.

i want to take input from a caller...that's it. i don't really care what the
configuration options are...but, i do control those. the meaning is crystal
clear...i'm taking input from a caller.

Quote:

In my framework I can reuse hash keys, I can scale, no one (except for
myself) can f**k it up and I don't rely on any magic. I exactly define
and document where I expect which data from and my scripts simply work
by following these rules.

i'm talking about large projects with multiple developers. we must work in
two different worlds.

<snip>

Quote:

>as it is, you mean that 'id' is possibly in post and/or get. and, that each

Quote:

>>context (post/get) means for 'id' has different meanings or should direct
>>your application to take differnt action. that's dangerous business.

>
Nope, it's absolutely correct behaviour and follows the different
semantics of GET and POST as defined in the HTTP standard.

i'm not talking about your gui. i'm talking about what happens to the data
you're about to process. that is defined by you, not an HTTP standard.

Quote:

>>what i am saying is that not recycling db "id's" and not overlapping input
>>hash key names ("id") and SPELLING OUT their *context* such as 'deleteId'
>>and 'loggedInUserId' not only takes the *magic* out of your application,
>>it
>>also makes it safe to use REQUEST.

>
Too much work for me. The last two steps are totally unnecessary with
proper handling of input data. In fact you're doing much more work to
keep your application safe just for the sake of using $_REQUEST.

no, it has nothing to do with making it safe to use request...at all. 'id'
should have specific meaning. if 'id' refers to one thing coming from post,
and another from get, do you think that's very clear to what entity 'id'
refers?

Quote:

I can easily reuse hashs and don't have to use this kind of "Hungarian
Notation" to spell out their context, simply because the context is
already given by the data source itself. There's nothing magic about it,
everything is exactly and well defined, quite contrary to $_REQUEST.

i don't care what kind of notation it is - and, it's
camel-casing...certainly NOT hungarian notation. hungarian, btw, is a
variable's datatype prefixing the variable. this is simply a case of giving
a variable a *meaningful* name...rather than, say, $tmp - meaningless!

Quote:

>>>post doesn't know
>>>that the user is doing something they ought not do, neither does get,
>>>nor
>>>cookie.

>
GET and COOKIE at least "know" that they shouldn't change the server
state. That's what POST is for.

where the hell are you getting this non-sense?!

Quote:

>>Indeed. They are merely superglobals, one shouldn't expect them to know
>>anything except what they are build for: holding the information they
>>are
>>suposed to hold. Using them wisely is up to the programmer that
>>implements
>>them.

>>
>>no problem there. and, if you have good design

>
With a lot of additional steps ...

those steps need only be handled in a few places and avoid the scenarios i
pointed out. i'd rather decouple than tie into an input mechanism. you
obviously don't.

Quote:

>>there is nothing unwise
>>about $_REQUEST.

>
... to keep the design safe.

lol. i think we're just at a point of personal preferences now. it seems
you've stopped listening. you certainly haven't countered any points i've
made thus far.

Quote:

>> you'll find another co-worker, oblivious to your
>>>post/get/cookie 'rule' and he'll kill your how dataset of users
>>>inadvertently.
>>>
>>What? My 'rule'?

>>
>>damn! in *your own example*, you expect a hash key of 'id'. all the while,
>>you expect it to have additional/specific meaning based on what
>>superglobal
>>it is in. that is an implicit rule! if your other developer is not aware
>>of
>>your rule, you code is shot to hell and your data will bear the results.

>
man documentation

sorry, you won't find anything in man.

Quote:

Other developers always have to follow the rules you define if they want
to get their code working with yours. Every single API requires that. If
they don't follow your rules - their problem.

omg! no, it's everyone's problem including customers. you should NOT set up
a system that doesn't take precautions to keep errors at bay...and away from
your data.

Quote:

>>And something tells me you haven't worked too often with other PHP
>>programmers, otherwise you surely would avoid $_REQUEST.

>>
>>wow! assumptive, are we not?! i work every day with 22 other professional
>>php developers. that's just with my full-time job. i work for two other
>>companies as a consultant...and, i'm not alone there either.

>
No offense intended, though, but I don't consider it professional to use
$_REQUEST. And I don't like consultants either, because too often they
are responsible for the worst crap of code. TheDailyWTF is full of such
stories.

well, i can't help your view of consultants. some are good and some are bad.
what can i say? given that i've been retained for almost four years by both
companies probably means they like my work.

Quote:

>>Good for you.
>>But this sounds as empty to me as: "That is why we try to develop
>>software
>>without bugs."

>>
>>perhaps you missed it, that ARCHITECTURE THAT DEFINES HOW THE SYSTEM
>>WORKS.
>>saying 'id' has a meaning to you in POST that it doesn't in GET simply
>>DOES
>>NOT DEFINE ANYTHING!!! it is magic, not architecture.

>
$_GET['id'] - get informations about a user
$_POST['id'] - modify the user record
$_SESSION['id'] - keep the user logged-in
>
This is architecture, not magic.

when i can get information about a user regarless of taking the 'id' via
post/get/cookie/session, it becomes magic to think GET actually means 'get
me some information', the same with post. they have no meaning...just a
standard on how the data is passed to a server.

Quote:

>>PS: Please try to use CAPITALS at the beginning of your sentences. Makes
>>it so much easier to read for me. :-)

>>
>>i'll think about it. :)

>
Obviously not.

no, i did think about it. obviously, my thought is, 'nah'. :)

Here Dale/Barry dude, have a cool (virtual)
beer/refreshment/whatever-you-like-to-drink.

Let's relax.
You pisses me off, and now I piss you off.

Who knows, maybe one day I see your POV or you see mine. Or hell freezes
over first, I don't know.
So let us drop this issue about $_REQUEST.
I think that is best for both our healths. ;-)

Regards,
Erwin Moller

"Erwin Moller"
<Since_humans_read_this_I_am_spammed_too_much@spam yourself.comwrote in
message news:4888b201$0$49839$e4fe514c@news.xs4all.nl...

Quote:

Here Dale/Barry dude, have a cool (virtual)
beer/refreshment/whatever-you-like-to-drink.
>
Let's relax.
You pisses me off, and now I piss you off.
>
Who knows, maybe one day I see your POV or you see mine. Or hell freezes
over first, I don't know.
So let us drop this issue about $_REQUEST.
I think that is best for both our healths. ;-)

it sounds fine to me. i get frustrated explaining things at times, but if i
got pissed off here i'd certainly question my sanity! :)

Dale:

Quote:

as for server 'state', please provide the quote from the rfc you listed
where is says one damned thing even *similar* to that.

What Micha was alluding to, I believe, was the property of
idempotence, a property which can distinguish GET from POST. GET is
conventionally idempotent because it should only be used for
retrieval, but POST may be used for such non-idempotent actions as
updating a database. In other words, POST is a potentially unsafe
method because it can have side-effects, but GET should be a safe
method - a method that doesn't change the _state_ of the universe, to
borrow Micha's turn of phrase.

Caveat:

| Naturally, it is not possible to ensure that the server does not
| generate side-effects as a result of performing a GET request; in
| fact, some dynamic resources consider that a feature. The important
| distinction here is that the user did not request the side-effects,
| so therefore cannot be held accountable for them.

(RFC 2616: 9.1.1)

[...]

Quote:

looks like however you implement OPTIONAL request methods is *clearly* up to
YOU.

Well, no, not if you want to conform to RFC 2616. If you do implement
optional methods, you "must" do so with the semantics described in
section 9. The semantics of GET and POST are quite different.

--
Jock

notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

re: notice and warning

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about