Req #41810 [Com]: Unable to catch Parse Errors

From: 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

« previous php.bugs (#191417) next »