Yes.. apparently it works. My mistake. I accidentally tested it in a context
with error suppression enabled.
Apparently there where some other reason for it not being gracefully caught
in production then. Going to have an extra look at it. Closing the bug in
the meantime.
~ Hannes
On 9 March 2011 17:01, Ferenc Kovacs <i...@tyrael.hu> wrote:
> tyrael@devel-tyrael:~/c$ php -f fatal.php
> PHP Fatal error: Call to a member function bar() on a non-object in
> /home/tyrael/c/fatal.php on line 9
> PHP Stack trace:
> PHP 1. {main}() /home/tyrael/c/fatal.php:0
> Houston we have a problem: Array
> (
> [type] => 1
> [message] => Call to a member function bar() on a non-object
> [file] => /home/tyrael/c/fatal.php
> [line] => 9
> )
>
> as I mentioned, it works.
>
> Tyrael
>
>
> On Wed, Mar 9, 2011 at 4:59 PM, Hannes Landeholm <landeh...@gmail.com>wrote:
>
>> No you can't gracefully handle all fatal errors. The shutdown function
>> will be called after *some* fatal errors but not all of them. See the bug I
>> reported here for more information: http://bugs.php.net/bug.php?id=54195
>>
>> ~Hannes
>>
>>
>> On 9 March 2011 16:12, Ferenc Kovacs <i...@tyrael.hu> wrote:
>>
>>> 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
>>>>>> >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
