php-general Digest 20 May 2012 20:30:08 -0000 Issue 7818
Topics (messages 317908 through 317912):
Re: errors not showing
317908 by: Simon J Welsh
317909 by: Tim Dunphy
317910 by: tamouse mailing lists
317912 by: Maciek Sokolewicz
Re: regexp novice
317911 by: Geoff Shang
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:
> hello, list!
>
> I have 'error_reporting = E_ALL' set in my php.ini file. However when
> I run a php script that has errors in it all that happens is that the
> page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
> don't show up in the browser and how to correct this?
>
>
> Thanks
> Tim
You also need to set display_errors to On.
---
Simon Welsh
Admin of http://simon.geek.nz/
--- End Message ---
--- Begin Message ---
Hello Simon,
Thanks for your response.
However I still can't seem to get errors to show up.
[dunphy@localhost:~/jf-current] #cat /private/etc/php.ini | grep -e
error_reporting -e display_errors
; display_errors
; error_reporting
error_reporting = E_ALL & E_NOTICE
;error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On
; separately from display_errors. PHP's default behavior is to suppress those
; Eval the expression with current error_reporting(). Set to true if you want
; error_reporting(0) around the eval().
[dunphy@localhost:~/jf-current] #sudo apachectl -t
Syntax OK
[dunphy@localhost:~/jf-current] #sudo apachectl restart
[dunphy@localhost:~/jf-current] #uname -a
Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386
I was wondering if there might be something else I might've missed?
Thanks
Tim
On Sat, May 19, 2012 at 11:57 PM, Simon J Welsh <si...@welsh.co.nz> wrote:
> On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:
>
>> hello, list!
>>
>> I have 'error_reporting = E_ALL' set in my php.ini file. However when
>> I run a php script that has errors in it all that happens is that the
>> page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
>> don't show up in the browser and how to correct this?
>>
>>
>> Thanks
>> Tim
>
> You also need to set display_errors to On.
> ---
> Simon Welsh
> Admin of http://simon.geek.nz/
>
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--- End Message ---
--- Begin Message ---
On Sat, May 19, 2012 at 11:16 PM, Tim Dunphy <bluethu...@gmail.com> wrote:
> Hello Simon,
>
> Thanks for your response.
>
> However I still can't seem to get errors to show up.
>
> [dunphy@localhost:~/jf-current] #cat /private/etc/php.ini | grep -e
> error_reporting -e display_errors
> ; display_errors
> ; error_reporting
> error_reporting = E_ALL & E_NOTICE
> ;error_reporting = E_ALL & ~E_DEPRECATED
> display_errors = On
> ; separately from display_errors. PHP's default behavior is to suppress those
> ; Eval the expression with current error_reporting(). Set to true if you want
> ; error_reporting(0) around the eval().
>
> [dunphy@localhost:~/jf-current] #sudo apachectl -t
> Syntax OK
>
> [dunphy@localhost:~/jf-current] #sudo apachectl restart
>
>
> [dunphy@localhost:~/jf-current] #uname -a
> Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
> 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386
>
> I was wondering if there might be something else I might've missed?
>
> Thanks
> Tim
>
> On Sat, May 19, 2012 at 11:57 PM, Simon J Welsh <si...@welsh.co.nz> wrote:
>> On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:
>>
>>> hello, list!
>>>
>>> I have 'error_reporting = E_ALL' set in my php.ini file. However when
>>> I run a php script that has errors in it all that happens is that the
>>> page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
>>> don't show up in the browser and how to correct this?
>>>
>>>
>>> Thanks
>>> Tim
>>
>> You also need to set display_errors to On.
>> ---
>> Simon Welsh
>> Admin of http://simon.geek.nz/
>>
>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Are these syntax errors or run-time errors? The former won't display
to the page at all, as they abort PHP before that point. Those written
to wherever PHP is set to log errors, which might be the same as the
apache error log unless you've set something specifically for it in
php.ini.
The best way I've found to suss out syntax errors is to "lint" the
source file with php -l from the command line.
On the other hand, if they are not syntax errors, then make sure you
set error_reporting and display_errors (I also always set
display_startup_errors as well) soon enough to catch them (and that
nothing you include turns them off).
--- End Message ---
--- Begin Message ---
On 20-05-2012 07:17, tamouse mailing lists wrote:
Are these syntax errors or run-time errors? The former won't display
to the page at all, as they abort PHP before that point. Those written
to wherever PHP is set to log errors, which might be the same as the
apache error log unless you've set something specifically for it in
php.ini.
The best way I've found to suss out syntax errors is to "lint" the
source file with php -l from the command line.
On the other hand, if they are not syntax errors, then make sure you
set error_reporting and display_errors (I also always set
display_startup_errors as well) soon enough to catch them (and that
nothing you include turns them off).
I always find it useful to check these values not by grep'ing the
php.ini file, but by checking phpinfo() output. Just make a new file with
<?php
phpinfo();
in it, and run it in the browser. That will show you the values of
display_errors and error_reporting that are actually used. I have seen
cases where the php.ini file a person thought was being used was
actually NOT used, and as such changing values inside that file had no
effect.
- Tul
--- End Message ---
--- Begin Message ---
Stuart Dallas" <stu...@3ft9.com> wrote:
On 18 May 2012, at 14:50, Jim Giner wrote:
Daft is a little harsh. :) 00:40 is just not a time value that is
generally accepted.
It may appear harsh, but as far as I'm concerned it is daft to make
assumptions like that. You've essentially disallowed 12:nn am, but allowed
1:nn am, 2:nn am, 3:nn am, etc, because you're not validating the data in a
non-ambiguous way. I have no idea what you're developing, but you're making
a big assumption about the data that you're getting, which may appear
reasonable to you, but to me it's daft. Nothing personal, just my opinion,
which is all I have to offer.
Unless I've missed something, he hasn't disallowed 12:nn am, only 00:nn.
If you're going to only accept 12-hour input, this is the right thing to
do. 00:nn is not a valid 12-hour representation - only times from 1:nn to
12:nn are acceptable. If you were to accept 00:nn, you'd have to also
accept 13:nn-23:nn as well, for consistancy.
Granted, not specifying am or pm adds a layer of ambiguity, but maybe
that's not relevant for this query. For example, maybe there's also a
select field that has am and pm as options.
As it appears that accepting only 12-hour input is part of the brief, Jim
is IMHO doing the right thing.
Geoff.
--- End Message ---
