Req #41810 [Com]: Unable to catch Parse Errors
| From: | shelby at coolpage dot com | Date: | Mon, 16 Mar 2015 18:42:19 +0000 |
| Subject: | Req #41810 [Com]: Unable to catch Parse Errors | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-191417@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=41810&edit=1
ID: 41810
Comment by: shelby at coolpage dot com
Reported by: d dot albano at gmail dot com
Summary: Unable to catch Parse Errors
Status: Not a bug
Type: Feature/Change Request
Package: *General Issues
Operating System: Linux
PHP Version: 5.2.3
Block user comment: N
Private report: N
New Comment:
Ah rasmus and I can butt heads again after so many years hiatus.
In my case, I'm catching all output from the server in an invisible iframe, because I am
expecting it to be JavaScript that is a callback to a function that processes JSON output from the
server. Or in another case for uploading files, I set the UA <form> target to an invisible
iframe with an onload callback to indicate the file was uploaded by the server.
In both of these cases I don't see parse errors at all. Everything silently fails. Now
let's say I need to make incremental edits some years in the future and have long since
forgotten this issue. So I will be scratching my head and digging again.
One way to add complexity to programming is to create a zillion special cases. These really do
accumulate across the many frameworks and languages we developers use.
Fix the damn weakness and stop whining Rasmus.
It only took you how many years to finally implement proper hash_password in 5.5.
Previous Comments:
------------------------------------------------------------------------
[2012-10-05 21:05:21] rasmus@php.net
Even in the templating case there really is no excuse for pushing templates with
parse errors to production. Running "php -l" as part of your pre-push testing is
the expected bare minimum and hopefully you have actual tests you run with decent
code coverage as well. You could also run it in your pre-commit hook in your VCS.
Addressing this in PHP itself is extremely low-priority which means it will
likely never happen.
------------------------------------------------------------------------
[2012-10-05 20:52:43] airetamstrm at gmail dot com
Contrary to what others have said here, require/include_once do NOT (always)
happen at compile time.
Otherwise, it would be impossible to do this:
<?php
foreach(glob('/path/to/php/includes/*') as $match) {
if (is_dir($match)) {
foreach (glob($directory.'/*.php') as $filename) {
require_once(($filename);
}
} else if (is_file($match)) {
foreach (glob($directory.'/*.php') as $filename) {
require_once(($filename);
}
}
}
?>
I've found the best way to work around this problem is to use eval, which is a
poor
solution at best. There really should be a way to catch this, considering PHP is
an
interpreted / templating language. Regardless of the intended functionality /doc
of
require/include_once there absolutely should be some mechanism to do this. See
below for an
example on how to at least silence parse errors:
function safeInclude($filename) {
$fc = file_get_contents($filename);
eval('?>'.$fc);
}
However, in the defense of the developers, if you're checking code for errors
before
including it, you're one or more of the following:
1) Building convenience code to help with rapid development
2) Pulling in code that you don't fully trust from others that may be buggy
3) Doing silly, inexcusable things with production
4) Templating and thus #2
Fixing this bug likely be the most help to #1 and #4. If you're doing #4 you
need to fire
someone, if you're doing #3 you need to fire yourself. At the very least, if
you're trying
to do this you should review WHY you're trying to do this, and see if perhaps
there's
something else terribly wrong with your design approach.
I'm a #4 and would like it if someone could look at fixing this.
------------------------------------------------------------------------
[2012-09-15 21:45:32] rasmus@php.net
This can't be done safely within the same parser instance as your main script.
You will need to create a separate instance, as in system("php -l $script"); to
do that check. I would suggest you do this once when these scripts are created
and move them into a "checked" directory or something so you don't do it on every
include.
------------------------------------------------------------------------
[2012-09-15 20:53:11] james dot dobb at gmail dot com
I agree that this, perhaps not a bug but a missing feature needs to be addressed,
There should be a secure way of including scripts from another script and be able
to continue the calling script if an error occurs, the lack of functionality here
is causing me a major headache.....
------------------------------------------------------------------------
[2010-07-02 13:41:24] pajoye@php.net
It is not, please double read the manual about require/include_once.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=41810
--
Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1