FYI you can gracefully handle every error. even the non-recoverable ones. if you check my library you can test it also, I have an example file for every non recoverable error (E_PARSE, E_CORE_ERROR, etc.).
from my point of view, every userland error should be catchable from userland. the max execution time servers two purpose: - it saves you from shooting you in the leg (will abort an infinite loop for example) - it could be used as a tool by the sysadmin to restrict the cpu usage in a shared hosting environment. the ability to execute code via register_shutdown_function after the "Maximum execution time exceeded" fatal error thrown by the engine makes the second point void (except if you disable the register_shutdown_function, which you would do of course in a shared environment). so I think that it should be only used for the first problem, in which case it could be catchable IMO, because it doesn't leave the engine in an unstable state. Tyrael On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm <landeh...@gmail.com>wrote: > That's not a problem. Timeouts should be non-recoverable IMO as it's a > serious problem and I think most PHP developers would agree with this. > Making errors "recoverable" is difficult to implement, could have > performance penalties and be conceptually wrong when the state is defined as > "never allowed to happen". > > What I'm concerned about is that all problems should be able to be handled > gracefully from the register_shutdown_function like showing an informative > page, setting HTTP status, logging the problem, sending an error report, > etc. Not all fatal errors can be caught this way, including script timeout. > > ~Hannes > > > On 9 March 2011 15:39, Ferenc Kovacs <i...@tyrael.hu> wrote: > >> no, it only means that you cant return to the original scope and continue >> the execution of your script. >> as you can't throw exceptions also, because your code is running without a >> stack frame. >> you can check out the https://github.com/Tyrael/php-error-handler its a >> little class which operates with register_shutdown_function to allow >> handling non-recoverable errors before halting. >> there are too many case in the php src where non-recoverable errors are >> triggered for non fatal problems. >> that should be changed, so open a bugreport if you think you found one, >> where isn't neccessary to halt the execution. >> >> Tyrael >> >> >> On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm <landeh...@gmail.com>wrote: >> >>> You mean the shutdown function is called and 1 nanosecond later PHP >>> crashes >>> so you don't have time to do anything? >>> >>> ~Hannes >>> >>> On 9 March 2011 15:27, David Muir <davidkm...@gmail.com> wrote: >>> >>> > Hmm, I think I worded that poorly. >>> > A function registered with register_shutdown_function does execute when >>> > the max_execution_time is exceeded. >>> > What it doesn't let you do is to recover in the same way an error >>> > handler would let you. >>> > >>> > David >>> > >>> > On 09/03/11 22:56, Hannes Landeholm wrote: >>> > > I second making time limit reached catchable. All non catchable fatal >>> > errors >>> > > are a problem for me. I need to handle problems gracefully to ensure >>> the >>> > > stability of production systems instead of PHP just killing itself >>> > without >>> > > warning. I just reported a similar issue: >>> > > http://bugs.php.net/bug.php?id=54195 >>> > > >>> > > A simple way to implement this would be to register a function that >>> would >>> > be >>> > > called N seconds before the script would timeout. >>> > > >>> > > register_timeout_handler(2, function() { die("PHP timed out."); }); >>> > > >>> > > It would be called just as a shutdown function - in fact I'd like to >>> use >>> > the >>> > > same function as my shutdown function and get the error with >>> > > error_get_last(). Of course set_time_limit(0) could be used in this >>> > function >>> > > to prevent the timeout of the timeout handler. This does not >>> "prevent" >>> > > timeout since set_time_limit could have been called by the script >>> before >>> > the >>> > > timeout anyway. >>> > > >>> > > On that note I also miss a function which returns the time the script >>> can >>> > > keep running for. If that calculate needs to be calculated to >>> implemented >>> > to >>> > > implement this, why not make the value available to the PHP script? >>> > > >>> > > ~Hannes >>> > > >>> > > On 9 March 2011 02:30, David Muir <davidkm...@gmail.com> wrote: >>> > > >>> > >> Although it doesn't let you recover from a timeout, you could use >>> > >> register_shutdown_function to gracefully exit after a fatal error. >>> > >> >>> > >> register_shutdown_function(function(){ >>> > >> $error = error_get_last(); >>> > >> if($error && $error['type'] === E_ERROR){ >>> > >> echo 'PHAIL! Oh noes, something went wrong!'; >>> > >> // do whatever else you need to do before quitting >>> > >> } >>> > >> }); >>> > >> >>> > >> Cheers, >>> > >> David >>> > >> >>> > >> On 08/03/11 22:39, Pierre Joye wrote: >>> > >>> hi, >>> > >>> >>> > >>> is not the goal of this setting to prevent that a script runs >>> longer >>> > >>> than a given time? A catchable error will prevent that to happen. >>> > >>> >>> > >>> On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann < >>> sebast...@php.net> >>> > >> wrote: >>> > >>>> Could set_time_limit() be changed in such a way that it triggers >>> a >>> > >>>> catchable fatal error instead of a fatal error? Thanks! >>> > >>>> >>> > >>>> -- >>> > >>>> Sebastian Bergmann Co-Founder and Principal >>> > >> Consultant >>> > >>>> http://sebastian-bergmann.de/ >>> > >> http://thePHP.cc/ >>> > >>>> -- >>> > >>>> PHP Internals - PHP Runtime Development Mailing List >>> > >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>>> >>> > >>>> >>> > >>> >>> > >> >>> > >> -- >>> > >> PHP Internals - PHP Runtime Development Mailing List >>> > >> To unsubscribe, visit: http://www.php.net/unsub.php >>> > >> >>> > >> >>> > >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > >>> >> >> >