Beginner question: I have done around 30 hours trying to sort out an error handler, essential as I am not a great programmer. I am 95% sure I can’t do anything about fatal-fatal errors but I am still 5% hopeful.
My error handler was working well sending out emails and text messages when it encounters problems but then I got an empty page with just:
Fatal error: Cannot use try without catch or finally
in /directory/ etc ...filename.php on line 999
(I had accidentally deleted the catch block.) The question: Someone somewhere mentioned htaccess 500 pages.
I did not understand what was described when I read it. I have done almost nothing with htaccess up to now.
Is there a way to trip some sort of static page? (I am 95% sure I can do nothing but I am stuck and still have a 5% hope and this is really important for me.) I am still running PHP 5.6 but do not want to upgrade to 7 yet. Catching these errors is far more important for me than the warnings, notices, deprecateds etc that I can catch.
Update
I saw that question and used some of the techniques there BUT it is 11 years old, huge, partly outdated and does NOT primarily address the problem I now want to solve.
I have no problem dealing with "fatal errors" such as calling a non existent function. My problem is about errors found when the script is parsed and are "unrecoverable". In my case a missing catch when a try is present.
The other answer, answers this in parts but not in ways that I can seem to use. I think there maybe a way of forcing a 500 error rather perversely by stopping error display which I will investigate soon/tomorrow. I would be grateful for 24 hours to check. I am quite happy for someone more knowledgeable to put up a better question/answer and useful info could be culled from that thread but, frankly it is a mess unsurprisingly after 11 years.
Answer - almost
Switch display_errors to off and you have a 500 error. Sadly I cannot get an .htaccess redirect to work (404 works fine). If you are good with .htaccess hopefully you will have some joy.
In some discussions there is talk of some 500 errors being "CORE" errors and REALLY unrecoverable even by .htaccess. My logs are very sparse and I cannot see any useful indication if this is the case for the catch when a try is present error.
(With a big thank you to #Dharman (if it works)). PS Will tidy this up when/if I get to the end of this.)
I don't think PHP can do anything with parse errors (or other errors during the compilation phase), but you should be able to configure your web server to display an error page of your choosing.
You don't say what web server you are using, but for example with Apache these are the Custom Error Response settings. Your errors will be HTTP 500 errors.
Related
The Slim Framework is good - seriously good. One of the issues I have run into is with the way it handles errors. In vanilla PHP code I occasionally use trigger_error statements as a debug aid. In vanilla PHP this has no untoward consequences since by default trigger_errors are E_USER_NOTICE type errors that do not stop the script dead in its tracks. However, in Slim things appear to work differently. A benign trigger_error causes it to throw a wobbly and an HTTP 500 is returned.
I thought this could be corrected by
Changing the mode to development or something but the docs state that this makes no difference whatsoever to the way Slim works internally.
Next port of call - changing the slim error logging level
$app = new \Slim\Slim(array('log.level' => \Slim\Log::ERROR);
does not quite have the same effect as PHP's error_reporting. Setting it stops the error from floating up to the error.log file (the default error logger used by Slim) but crucially it does not stop the HTTP 500.
I have come across forum posts that suggest replacing the default Slim::handleErrors method. That would be easy but I wonder if that is not incorrect. What is the right way to stop Slim coming to a dead halt when it runs into a wholly innocuous trigger_error? I can well avoid this but I may rely on other code that may have such statements. I would much appreciate any help
The answer turns out to be quite simple. I figured it out by checking out the handleErrors function in slim.php. Just issue a
error_reporting(E_ALL & ~E_USER_WARNING);
prior to where the trigger_error is called and you are in business. Somewhere down the line Slim is changing the default PHP error_reporting to include E_USER_WARNING.
I was thinking of using HHVM in my development environment. However, I have encountered two significant issues.
First, no matter what I try, I cannot get HHVM to display a PHP stack trace in the browser window when an exception or error occurs. I've tried using set_error_handler and various other approaches. Has anyone figured out a way to display errors and exception stack traces in the browser window?
Second, the error log file is filled with "\n". I know that is supposed to cause a carriage return. However, it's not. Instead, it just makes the logs hard to read. Has anyone figured out a way to get rid of all of the "\n" in the log files?
I'm pretty sure I'm not only one who has noticed that simple parse errors on PHP, if present in very nested scenarios (eg, an object instance which references another object instance which references another object instance that has a very tiny parse error, all of them being auto loaded) can make PHP hang forever instead of reporting the parse error and halting the execution like it would normally do — I've seen this many times and in very different code bases, always with the proper error_reporting setting set.
Is there any way around it? i.e., can it be forced to display the parse error report as it should somehow?
For the record, I'm 100% sure these hangs were caused as a result of PHP not handling the parse error correctly, as I have debugged this behaviour many times; the reason I ask is because when these hangs happen one is basically left in the dark, not even being able to tell whether PHP is acting funny or there really is an malfunctioning loop in the code somewhere — this takes time to debug, time that could be saved if, you know, PHP reported the parse error like it should.
As partially mentioned in the comments, error_reporting(E_ALL) can help display all errors. You might also have to use ini_set and make display_errors have a value of on.
Personally, I think your question is not very clear, and you should improve formatting and make it more understandable.
UPDATE: Your server / computer you're running the code on seems to be very slow. No 'hanging-around' should really occur. Or could you describe it with further detail?
Also, you might be stuck in an infinite or near-infinite loop. Check closely in your code, because unless you post all your code, this is the limit to which we can help you.
UPDATE 2: It seems that you may have mistyped the name of an object when you are trying to call it. Otherwise, it may be that you have not declared your object correctly.
Most likely one or the other.
Turns out the culprit was xdebug.collect_params, which the documentation very correctly suggests to keep disabled. Certain errors were simply generating a very large amount of data in the arguments of the call stack trace which exhausted xdebug with collect_params set to 4 and made xdebug and by extension PHP to hang, even though I have a custom exception handler in place which never actually retrieves the stack trace from xdebug, but apparently xdebug collects this data anyway.
This was hard to debug because: a) it was not straightforward to replicate b) profiling with xdebug did not help c) stepping through the code with xdebug + dbgp was not helping either d) almost no trace (no pun intended) was left other than very ocasionally logging the errors to the php error_log file and e) with a custom exception handler it was not obvious to suspect of xdebug, since I didn't involve it in the process of handling the exception, or so I thought.
So there is no such thing as the parse error of death, and I learned to never assume it's not my fault :) Hopefully this answer will help others in the future at least.
So I have a strange and quite ambiguous question, which I can't seem to find even a vague answer to anywhere on the internet.
I've written a bunch of classes which facilitate a checkout process. The entire process works perfectly fine on my development server, but when I upload it to my client's server the code dies about halfway through (I can tell because I know which actions were and were not performed).
Debugging the code on my development server yields no warnings or errors (and rightly so, since it WORKS locally).
When running the website on the remote server, the code dies with '?>' as the only output. There's just way too much code to post in here, and I can't narrow it down to a specific line or even file, since I don't get any error output (and as I mentioned above, debugging it is of no use because it runs fine in the location for which I have access to a debugger).
So tldr; my question is: Is there any generic reason for why this ?> might be echoed to the page? The nature of this text suggests that it's terminating and for some reason printing the PHP ending terminator tag?
I have no clue. I understand that this problem is very hard to diagnose with what I've given you (and it's all I have to go on, as well) but even the slightest idea or suggestion would be infinitely helpful.
Thanks!
Sounds to me that you've used short open tags (<? or <?=), and it's disabled in your production environment.
You can find out if this feature is disabled by checking the short_open_tag PHP configuration option.
When in doubt, you can use some echo statements to help see just how far the code is getting. Perhaps you've got a quote mark out of place somewhere, causing the page to actually just print that part of the code. Or maybe you've already terminated the PHP somewhere, and then you write ?> again without needing to.
In terms of that being an actual error message though, I doubt it. My money's on some erroneous character(s).
You're using the url path / and the web server fetches index.html or something similar and not index.php. Try to directly access it.
I don't know if you are using zend, but they recommend not having a closing php tag in php only files (like classes) http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Maybe deleting the closing php tag will allow you an error message that will lead to the real problem.
I have tried looking everywhere for an answer but i can only find references to Unknown Type errors, this seems to be different.
I have installed a nightly snapshot build of solr (apache-solr-4.0-SNAPSHOT.war) which i have had to do because the pdfbox library that comes with stable is too old and would not read them. but that's another story.
What i have at the moment is an error from php SolrClient::AddDocuments() with the error message from the exception as 'Unknown style "html"', please can someone explain what could be causing this error.
Thanks in advance.
This appears to be a difference in the structures of the config files. I edited the schemea.xml and solr-config.xml files and the error disappeared. Exactly what change made it disappear I am not sure as I amde several at once.
Thats the best answer i have.