| Re: Undefined variable [message #181253 is a reply to message #181249] |
Thu, 25 April 2013 09:22   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 4/25/2013 3:03 AM, Chuck Anderson wrote:
> Jerry Stuckle wrote:
>> On 4/24/2013 4:02 PM, Chuck Anderson wrote:
>>> Question Boy wrote:
>>>> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>>> > On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>> >
>>>> >> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> >> <question....@hotmail.com> wrote:
>>>> >>> I have an simple MySQL/PHP app and it appears to be functional
>>>> >>> but the
>>>> >>> webmaster has informed me that it is throwing lots of errors. So he
>>>> >>> showed me the log file and I am trying to remedy the issues, but
>>>> >>> have
>>>> >>> a question.
>>>> >>> For instance, I have a block of code, such as:
>>>> >>> if ($iBookedBy=="Other") {
>>>> >>> echo '<option selected value="Other">Other</option>';
>>>> >>> } else {
>>>> >>> echo '<option value="Other">Other</option>';
>>>> >>> }
>>>> >>> which the log file reports as:
>>>> >>> PHP Notice: Undefined variable: iBookedBy
>>>> >>> Now I thought of trying:
>>>> >>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> >>> echo '<option selected value="Other">Other</option>';
>>>> >>> } else {
>>>> >>> echo '<option value="Other">Other</option>';
>>>> >>> }
>>>> >>> but am not sure if the server will break because the variable isn't
>>>> >>> set or if it will still throw an error because of the second,
>>>> >>> original, part of the if statement? Is this a good way to handle
>>>> >>> the
>>>> >>> problem, or am I going about this the wrong way and there is a
>>>> >>> better
>>>> >>> method?
>>>> >>> Thank you for your help.
>>>> >>> QuestionBoy
>>>> >> 1. Yes, it will prevent the error notice.
>>>> >> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>>> >> isset($iBookedBy)==TRUE.
>>>> >> 3. Your asking the question suggests that you are trying to write
>>>> >> code
>>>> >> and run it directly on a production server rather than testing on a
>>>> >> local server. The webmaster will be happier, and you will be much
>>>> >> more
>>>> >> productive, if you set up a local server like WAMP.
>>>> > Thank you for the reply.
>>>> >
>>>> > I was always under the impression that it was always beneficial to
>>>> > explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>>>> > waste my time anymore.
>>>> >
>>>> > My test server was not reporting any errors. I will look into which
>>>> > setting has to be changed.
>>>> >
>>>> > Thank you once again.
>>>>
>>>> Even setting my test server to debug mode, I don't seem to get the
>>>> errors reported on the production server?
>>>
>>> My guess is that you are running Php < 5.3 on your development machine,
>>> and the production server is running 5.3+. That is why your test system
>>> does not produce the errors and the production machine does. When I
>>> upgraded to Php 5.3 some of my older scripts threw lots of these errors.
>>> I found that the best way to correct them was to create a section near
>>> the top of the script where I set all variables needed by the script to
>>> their default values (usually either '', or 0). Add a comment and you're
>>> also creating useful documentation.
>>>
>>
>> Even PHP > 5.3 will give notices on these notices. I suspect you just
>> didn't have E_NOTICE enabled on your old scripts.
>
> Okay. My bad. I didn't remember that I enabled notices and deprecation
> errors when I upgraded to 5.3. I believe I wanted to see things that
> were going to become errors eventually, and to correct any sloppy coding
> I'd allowed myself to write when I was newer to Php and did not take it
> seriously - when it was more forgiving. When I did so I was hit with a
> slew of notices and I had to change a lotof "if ($_POST[submit'])"s to
> "if (isset($_POST[submit_form']))" ... and other things. It was a good
> exercise and it has improved the quality of my code a great deal.
>
Yup, it's easy to do.
>>
>> Setting variables to their default values is a good idea - but only if
>> their equivalent isn't defined in $_POST, $_SESSION, etc.
>
> That is not a problem for me. I do not initialize "REQUEST" variables
> (POST, GET, COOKIE, SESSION) - and I never have register_globals
> enabled, so setting a local variable to a default value never conflicts
> with the super global REQUEST variables.
>
I don't use $_REQUEST at all. I like to know where my data are coming
from.
> I set local variables to default values near the top of the script (like
> a prologue) and then I go through my REQUEST ($_POST, $_GET) variables
> and set a corresponding local variable to it's value which I then use in
> my script. I almost never use REQUEST variables directly within my
> script. This also forces me to remember to cleanse any user input.
>
I learned this way in C (actually way back in Fortran II). But I found
C++'s way of defining/initializing a variable where it's first used to
make my code cleaner. So now in PHP I initialize it when I'm ready to
use it - not at the top of the code. It's a matter of style, but I've
found it helps with cleaner code - a year later you don't have to go
looking back to see what it's default value is, for instance.
>>
>>> There is also a dirty "fix" (it is not really a fix)
>
> I think you read too fast. I stated right up front that this was not a
> fix.
>
> I have several old Php scripts I wrote that I rely on for personal
> utilities (calendar, accounting, log file analysis, ...). When I needed
> to use one "right now" after turning on NOTICE errors, I resorted to
> dropping an htaccess file into that directory that shut off the notices
> so I could use my utility and then come back later and fix it at my
> leisure (my scripts all still worked, even when using undefined variables).
>
> That's the only reason I mentioned this convenient short cut. It can
> put out the immediate fire. I believe I indicated more than once in my
> description that you should come back, re-enable notice errors and
> actually fix the problems.
>
No, I didn't read too fast. But too many new programmers take such
suggestions as fixes. And, of course, it doesn't work on all systems
(only Apache with the correct configuration).
>>> that will remove
>>> them immediately on the production machine. If you can not access
>>> php.ini (on a shared server) or do not want to make a global change to
>>> php.ini (the cause of those Notices should be found and corrected) put
>
> There's one.
>
>>> the following in a .htaccess file and place it in any affected, upper
>>> level directory.
>>>
>>> # error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
>>> php_value error_reporting 30711
>>>
>>> This will disable reporting of Notice level errors.
>>>
>>
>> That does NOT fix the problems. It merely hides them - which is his
>> current problem.
>
> It would also hide them on the production machine (where they should
> have not been displayed anyway) and, as I said, "put out the fire" for
> his client (even if unable to access php.ini on a shared host). He
> could then fix the scripts at a more leisurely pace and his client would
> be happy that he made the visible errors disappear almost instantly.
>
Unless it's a huge amount of bad code, it shouldn't take that long to
fix the problems.
>>> Here are some other combinations that can be useful for a quick and
>>> dirty fix to the production site after upgrading to Php 5.3.
>>>
>>> # php error level
>>> # error_reporting = E_ALL & ~E_DEPRECATED
>>> # php_value error_reporting 22527
>>>
>>> # error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
>>> # php_value error_reporting 22519
>>>
>>> With the fire put out you can correct the cause of the error reports at
>>> a more leisurely pace (after you upgrade to Php 5.3+ on your test
>>> system).
>>>
>>
>> Again, you are only hiding the problems, not fixing them!
>
> I know. And again, I also said as much.
>
> It's like using the faux spare tire most cars come with today. It does
> not fix your problem, but it does let you get where you're going for now
> - and you can deal with the real problem later.
>
Yes, but as I said before - too many people read such updates as
"fixes", even though you said they aren't.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]