# Feature request: ini setting for http 500 on fatal errors - Thread: https://externals.io/message/26092 - Original archive: https://news-web.php.net/php.internals/26092 - Started by Evert | Rooftop on 2006-10-19T18:21:19+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26092 — Evert | Rooftop — 2006-10-19T18:21:19+00:00 URL: https://externals.io/message/26092#26092 Excuse me if this has been discussed before, but I would like to know the stance on this issue, it's hard to search the buglist or mailing archives on stuff like http, 500 and fatal. Would it be hard to implement an ini setting for throwing a http 500 error on a fatal error? It's hard to make certain applications and have proper error handling if there is no way to do anything on a fatal error.. It would be even grander if php could try to run a fall-back script when something really bad happens, but just having that 500 on fatal errors would be awesome .. If this is not going to happen anytime soon, would you accept a patch? Evert --- ## #26093 — Rasmus Lerdorf — 2006-10-19T19:34:00+00:00 URL: https://externals.io/message/26092#26093 · In reply to: #26092 Evert | Rooftop wrote: > Excuse me if this has been discussed before, but I would like to know > the stance on this issue, it's hard to search the buglist or mailing > archives on stuff like http, 500 and fatal. > > Would it be hard to implement an ini setting for throwing a http 500 > error on a fatal error? It's hard to make certain applications and have > proper error handling if there is no way to do anything on a fatal error.. > > It would be even grander if php could try to run a fall-back script when > something really bad happens, but just having that 500 on fatal errors > would be awesome .. > > If this is not going to happen anytime soon, would you accept a patch? How would you implement it. Fatal errors can happen after output has already been sent in which case it is too late to change the http status. And if you haven't sent anything yet, as in you are using output buffering, then it is rather trivial to do in user space. Simply start you script by setting the status to 500 and change it to 200 when you know you have good output to send. That way if a fatal error happens, the 500 will be sent. -Rasmus --- ## #26094 — Evert | Rooftop — 2006-10-19T20:11:24+00:00 URL: https://externals.io/message/26092#26094 · In reply to: #26093 Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting `header()`'s wherever I need them.. Besides, in most of my script the business logic gets executed first, and this is where most errors can happen.. only after the presentation is done. So the solution would be, if fatal error is triggered, and `headers_sent()` is false then set the error to 500.. Is this possible? Evert Rasmus Lerdorf wrote: > Evert | Rooftop wrote: > > […] > > How would you implement it. Fatal errors can happen after output has > already been sent in which case it is too late to change the http > status. And if you haven't sent anything yet, as in you are using > output buffering, then it is rather trivial to do in user space. > Simply start you script by setting the status to 500 and change it to > 200 when you know you have good output to send. That way if a fatal > error happens, the 500 will be sent. > > -Rasmus --- ## #26095 — Brian Moon — 2006-10-19T20:20:30+00:00 URL: https://externals.io/message/26092#26095 · In reply to: #26094 Evert | Rooftop wrote: > Thats a smart idea.. I like that > > As for letting PHP do the 500, I tend to use output buffering everywhere > (i think most people do, supposed to be faster too) so I'm used to > setting `header()`'s wherever I need them.. You think wrong. There are very good reasons not to use output buffering. > Besides, in most of my script the business logic gets executed first, > and this is where most errors can happen.. only after the presentation > is done. > > So the solution would be, if fatal error is triggered, and > `headers_sent()` is false then set the error to 500.. This produces inconsistent behavior. I would not be in favor of it. I suggest you do as Rasmus suggested. Use `register_shutdown_function()` perhaps to have a function to change the status code before output is sent in your specific environment. -- Brian Moon ------------- http://dealnews.com/ It's good to be cheap =) --- ## #26096 — Evert | Rooftop — 2006-10-19T20:28:31+00:00 URL: https://externals.io/message/26092#26096 · In reply to: #26095 Brian Moon wrote: > Evert | Rooftop wrote: > > […] > > You think wrong. There are very good reasons not to use output > buffering. > calm down :S > > […] > > This produces inconsistent behavior. I would not be in favor of it. > > I suggest you do as Rasmus suggested. Use > `register_shutdown_function()` perhaps to have a function to change the > status code before output is sent in your specific environment. > Yea I do like that idea, didn't think of that approach. As for inconsistent behaviour.. It's not a huge deal, and the situation can easily described in the documentation. But yea, this is also why I proposed an ini setting. Rasmus' solution solves my problem though. Thanks a lot! Evert