PHP displays no output what-so-ever on some errors.

[Carpetsmoker]

Note: This discussion was originally in "Funny stuff" and moved to a new thread.

I don't think I've ever seen a simple string been put that awkwardly as that. I find it hard to believe it's possible.

Worst thing is, PHP errors suck.

$isengard->Template($vars;)

The semi-colon is in the wrong place. Oops.
PHP will just exit. No error whatever-so-ever. including from the commandline (Just exits with status 255).

I refactored 300 lines of code. Spot the error ... fun fun fun

[TerryP]

For the most part, PHP is very configurable about warnings and errors, or at least the FastCGI and mod_php setups respect that part of php.ini. You should be able to set it to something that will help you out.

The real problem is that between production-style settings and "I don't fucking care" developers, that in actual practice PHP is more like do anything you can to avoid dieing, even if that means doing something stupid. I have also known people to test on "Live" sites and turn off warnings on development machines. The responses from users are sometimes comical.

PHP is why I like the strongest possible type checking at compile and runtime, and why PHP would be my last choice of dynamic language for anything but a cheap web host or needing a PHP-based third party web app.

[Carpetsmoker]

For the most part, PHP is very configurable about warnings and errors, or at least the FastCGI and mod_php setups respect that part of php.ini. You should be able to set it to something that will help you out.

[~]% cat test.php 
<?php
        error_reporting(E_ALL);
        print php_info(;);
?>
[~]% php test.php
Exit 255

error_reporting is already at E_ALL in php.ini, but never hurts to set it twice. display_startup_errors is set to on.

If you have more info, please share. You would do me a huge favor.

Other then this, yeah, it works pretty well. The default messages kind of suck (No backtrace), but as you mentioned that can be configured quite easily.

[TerryP]

Assuming you're lucky enough to be using PHP 5, you might want to append E_STRICT, which isn't included with E_ALL. YMMV with it however, and expressly with the nature of the codebase you're using. Note that PHP's E_STRICT is not quite the same as Perls use strict.

Good PHP code should be E_ALL and E_STRICT compliant, documented, and well covered by unit tests and the like. Don't underestimate the utility of good unit tests.

I assume you know all the stuff about controlling where it sends errors; so you ought to be able to judge what's most convenient for you.

Originally Posted by Carpetsmoker

If you have more info, please share. You would do me a huge favor.

Yeah, don't use PHP. I doubt I can do you that favour though :-(.


I might also add that the PHP chatter isn't quite on topic, hardy har haarr

[Carpetsmoker]

Doesn't E_ALL include E_STRICT? I always thought E_ALL was *all* messages ...
In any case, I tried `E_ALL | E_STRICT' and I got the same effect.

From what I remember from PHP4, I never had this sort of problems ... I haven't done a lot of PHP programming for some time until I got landed in this job, in that time either something changed with PHP or something changed with my typing accuracy

And yeah, I used error_handler() and set a custom error handler to just quit on *any* error.

[TerryP]

Originally Posted by Carpetsmoker

Doesn't E_ALL include E_STRICT? I always thought E_ALL was *all* messages ...

I checked the manual page before posting, to be sure .


That does say something about the nature of PHP though, doesn't it?

[Carpetsmoker]

Originally Posted by TerryP

I checked the manual page before posting, to be sure .

That does say something about the nature of PHP though, doesn't it?

Yeah, it seem E_STRICT was added in PHP 5.3 for some stricter checking ...

XDebug seems interesting (Haven't tried it yet):
http://www.xdebug.org/index.php

[Carpetsmoker]

Ok, so I had some time to test stuff.

One typo consistently reproduces this error:

<?php
        error_reporting(E_ALL | E_STRICT);

        date(;)
?>

Today I tested this at my FreeBSD machine at home and I *did* get an error there as you would expect!

I compared the php.ini configuration files with the one used at the Fedora core machine I have at work, and they are almost exactly the same ... :-/

I'll do some testing with enabling/disabling extensions later (After-hours, since this is a production machine) ...

[Carpetsmoker]

The default error_reporting was set to:

error_reporting = E_ALL & E_NOTICE & E_DEPRECATED

Changing this to

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

Obviously the first one is not right, I overlooked the missing tildes in my earlier examinations of php.ini But as far as I understand it it should still work?

I also don't quite understand why the error_reporting() function doesn't work ...

[TerryP]

I would've just wrote it as

E_ALL ^ E_NOTICE ^ E_DEPRECATED

but to each eyes their own readability.


Why do you want notice and deprecated off? (E_ALL = 111011111111111; E_ALL & ~E_NOTICE & ~E_DEPRECATED = 101011111110111)