Re: [PHP-DEV] Class Access Modifiers
On Wed, Mar 9, 2011 at 3:23 PM, Chad Fulton wrote:
> Hello,
>
> On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles
> wrote:
> > Interesting question. My gut tells me not (as does three years of C#
> experience). I’m sure that everyone will have a different opinion on this
> but to me it seems taboo that a child class override the visibility of the
> parent class. For example, PHP currently does not allow you to override a
> method with a lower or higher visibility than the parent – I can’t go from
> protected to public or vice versa. Visibility must be maintained throughout
> the class hierarchy.
> >
>
> Actually, class properties and methods can have a higher visibility
> than their parents, just not a lower one.
>
> E.g.:
>
>
> error_reporting(E_ALL | E_STRICT);
>
> class foo {
>protected function bar() {
>
>}
> }
>
> class baz extends foo {
>public function bar() {
>
>}
> }
>
> class foobar extends baz {
>protected function bar () {
>
>}
> }
>
> ?>
>
> You get the following error:
>
> Fatal error: Access level to foobar::bar() must be public (as in class
> baz) in ...
>
> ---
>
> That said, I wouldn't think that visibility modifiers on classes need
> to follow the same pattern. In the case of properties and methods, I
> think the rationale is that child classes should be compatible from an
> interface standpoint with their parents. That same logic may not
> transfer to class visibility modifiers.
>
yes, every class should specify its own visibility.
Inheritance here does not make any sense, you only will be able to use
private classes at the cost of your entire class hierarchy being private too
.
>
> I am certainly no expert, but I'm curious what the use case is for
> class visibility modifiers?
>
> On Wed, Mar 9, 2011 at 7:11 AM, Hannes Landeholm
> wrote:
> > Currently I'm forced to use huge internal classes for my framework
> because
> dividing them into smaller classes would expose internal behavior to the
> "outside"... the application layer.
> >
>
> This doesn't necessarily make sense to me. Isn't it the
> end-developer's problem if they start instantiating classes in weird
> ways?
>
Well, that depends on who is your end-user?
Current object model works well for small-to-mid size application, but it
does not allows to write *safe* libraries
safe: to don't break client code, because of wrong client code.
> It doesn't seem the same as having a private method, since in that
> case the end-developer presumably already has an object instance, and
> you want to guide them to the correct interface for interacting with
> it, whereas in an application, one would think that the end-developer
> wouldn't simply be instantiating classes by themselves all over the
> place.
>
> Chad
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: [PATCH] Bug #49852 & Bug #53065 - Adding spl_autoload_case_sensitivity()
Do you use lowercase paths and have capitals in your class names? That is really where this goes into. Much of PEAR and just about all of the frameworks are following a specific area. The main key item here is that \My\Class is generally in a folder like My/Class.php. Right now spl_autoload would translate this to look at: my/class.php by default which one would likely think that it would be My/Class.php being the one that would be autoloaded since we did not type it lowercase. Regards, Mike On Wed, Mar 9, 2011 at 1:06 PM, Michael Maclean wrote: > On 09/03/11 13:34, Mike Willbanks wrote: > >> It seems like the only potential BC break is on linux if people were >> using all lowercase paths. To me it would seem like this is really >> not the case or would happen only sometimes. > > I'd have trouble finding a single one of my apps that had a path with any > uppercase characters at all. They all run on Linux. > > -- > Cheers, > Michael > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Access Modifiers
class modifiers should follow the same modifiers and semantic that methods:
T_PUBLIC, T_PROTECTED and T_PRIVATE should be used.
nowadays all classes are public...
T_PUBLIC: everybody can see it, everybody can subclass it
T_PROTECTED: visible only within its ns, but everybody can subclass it
T_PRIVATE: visible only within the same ns, subclass allowed only within its
ns
namespace A {
class Pub { }
protected class Prot { }
private class Priv { }
}
namespace B {
class Foo extends \A\Prot { } // legal, no matter Foo visibility
class Baz extends \A\Priv { } // error, no matter Baz visibility
new Foo(); // ok
new Baz(); // ok
new \A\Pub(); // ok
new \A\Prot(); // error, class is protected
new \A\Priv(); // error, class is private
}
in the example "A" exposes classes "Pub" and "Prot", but you cannot
instantiate class "Prot"
So... does it mean that class "Priv" cannot be used outside "A"? no, you can
always return a reference.
namespace A {
class F {
static function getE() { return new E; }
}
private class E { }
}
var_dump( \A\F::getE() ); // object \A\E
Martin Scotta
On Wed, Mar 9, 2011 at 3:23 PM, Chad Fulton wrote:
> Hello,
>
> On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles
> wrote:
> > Interesting question. My gut tells me not (as does three years of C#
> experience). I’m sure that everyone will have a different opinion on this
> but to me it seems taboo that a child class override the visibility of the
> parent class. For example, PHP currently does not allow you to override a
> method with a lower or higher visibility than the parent – I can’t go from
> protected to public or vice versa. Visibility must be maintained throughout
> the class hierarchy.
> >
>
> Actually, class properties and methods can have a higher visibility
> than their parents, just not a lower one.
>
> E.g.:
>
>
> error_reporting(E_ALL | E_STRICT);
>
> class foo {
>protected function bar() {
>
>}
> }
>
> class baz extends foo {
>public function bar() {
>
>}
> }
>
> class foobar extends baz {
>protected function bar () {
>
>}
> }
>
> ?>
>
> You get the following error:
>
> Fatal error: Access level to foobar::bar() must be public (as in class
> baz) in ...
>
> ---
>
> That said, I wouldn't think that visibility modifiers on classes need
> to follow the same pattern. In the case of properties and methods, I
> think the rationale is that child classes should be compatible from an
> interface standpoint with their parents. That same logic may not
> transfer to class visibility modifiers.
>
> I am certainly no expert, but I'm curious what the use case is for
> class visibility modifiers?
>
> On Wed, Mar 9, 2011 at 7:11 AM, Hannes Landeholm
> wrote:
> > Currently I'm forced to use huge internal classes for my framework
> because
> dividing them into smaller classes would expose internal behavior to the
> "outside"... the application layer.
> >
>
> This doesn't necessarily make sense to me. Isn't it the
> end-developer's problem if they start instantiating classes in weird
> ways?
>
> It doesn't seem the same as having a private method, since in that
> case the end-developer presumably already has an object instance, and
> you want to guide them to the correct interface for interacting with
> it, whereas in an application, one would think that the end-developer
> wouldn't simply be instantiating classes by themselves all over the
> place.
>
> Chad
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: [PATCH] Bug #49852 & Bug #53065 - Adding spl_autoload_case_sensitivity()
On 09/03/11 13:34, Mike Willbanks wrote: It seems like the only potential BC break is on linux if people were using all lowercase paths. To me it would seem like this is really not the case or would happen only sometimes. I'd have trouble finding a single one of my apps that had a path with any uppercase characters at all. They all run on Linux. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Bug #49852 & Bug #53065 - Adding spl_autoload_case_sensitivity()
I was just thinking about this again and have a working patch for this.
It seems like the only potential BC break is on linux if people were
using all lowercase paths. To me it would seem like this is really
not the case or would happen only sometimes. The quick solution is to
utilize the following patch:
Index: ext/spl/php_spl.c
===
--- ext/spl/php_spl.c (revision 306413)
+++ ext/spl/php_spl.c (working copy)
@@ -229,7 +229,7 @@
zval *result = NULL;
int ret;
- class_file_len = spprintf(&class_file, 0, "%s%s", lc_name,
file_extension);
+ class_file_len = spprintf(&class_file, 0, "%s%s", class_name,
file_extension);
#if DEFAULT_SLASH != '\\'
{
It would seem that this could be addressed for PHP Next with the BC
break (since it is very unlikely to really hit).
Regards,
Mike
On Tue, Feb 22, 2011 at 9:04 PM, Mike Willbanks wrote:
> I think it would be better just to fix the issue in the code. If you
> run include 'My/Path/To/File.php' does it lowercase it? It does not.
> The expected behavior would to not lowercase it. There are ways that
> this could be fixed directly in the code. The only real requirement
> that it looks like the need for lowercase is for the hash table that
> is internally maintained by spl_autoload for the loading of classes.
>
> To fix this w/o a BC break and give the expected behavior, it could
> look for the class first by lowercasing the path and then secondarily
> look by the correct case (or the opposite). The only real usefulness
> of the default behavior is for windows users whereas the majority of
> installs is on *nix platforms.
>
> The other way (and cleaner IMO) than the current patch if the above
> wouldn't work is to add a forth parameter to spl_autoload_register to
> tell it to by type sensitive. The only BC break that is really
> possible here is for *nix users that are expecting it to always be
> lowercase, however, this seems to be more or less an edge case and
> should ultimately just be fixed. I have not seen one project that
> utilizes the spl_autoload default functionality since their class
> naming structure generally consists of upper and lowercase letters.
>
> To keep consistency it could certainly be a boolean with the function
> declaration of (keeping BC of course):
> bool spl_autoload_register ([ callback $autoload_function [, bool
> $throw = true [, bool $prepend = false [, bool $case_sensitive = false
> )
>
> I can build a patch for this route if someone would like... I just
> think that instead of the SplClassLoader proposal something also needs
> to happen with the spl_autoload area as well.
>
> Regards,
>
> Mike
>
>> Wouldn't it be better to join forces with the SplClassLoader proposal[1]?
>> A C implementation of PSR-0 has been prpoposed [2] as well, and would be
>> nice to get something like that into 5.next
>>
>> However for your imminent performance needs, you should be aware that an
>> hash map based autoloaders can be fast as well [3].
>>
>>
>> [1] http://wiki.php.net/rfc/splclassloader
>> [2] http://blog.runpac.com/post/splclassloader-php-extension-benchmarks
>> [3]
>> http://weierophinney.net/matthew/archives/245-Autoloading-Benchmarks.html
>>
>> Best
>> ar
>>
>>
>> On Wed, Jan 12, 2011 at 11:53 PM, Marc Easen wrote:
>>
>>> Hello again,
>>>
>>> Has anyone had a chance to look at my patch?
>>>
>>> Forgive me for being quite eager to get this into trunk, as it will improve
>>> the performance of all PHP Frameworks which currently implement their own
>>> autoloader method due to the oddities of the SPL autoloader.
>>>
>>>
>>>
>>> Kind Regards
>>> Marc
>>>
>>>
>>> On 26 Dec 2010, at 13:20, Marc Easen wrote:
>>>
>>> Hello everyone,
>>>
>>> Firstly I would like to introduce myself, my name is Marc Easen and I've
>>> working with PHP for past 6 years or so. I'm really excited to see where PHP
>>> is going with the addition of namespaces and now traits, and hopefully I'm
>>> able to contribute back to PHP community.
>>>
>>> I've currently working on a high performance PHP Framework based on version
>>> 5.3.3+ (5.3.99-dev for traits). Due to the high performance nature of this
>>> framework I've been looking at ways of improving the loading of the classes.
>>> It seems by default the spl_autoload() function lowercases the class name
>>> before trying to locate the file, a couples of users have reported this
>>> previously and have requested a fix (bug #49852
>>> http://bugs.php.net/bug.php?id=49852 & bug #53065
>>> http://bugs.php.net/bug.php?id=53065). spl_autoload() lower casing the
>>> class names when it is trying to locate the file does not work on *nix based
>>> system in a lot of PHP Frameworks - Zend Framework being on of them.
>>>
>>> Understanding the requirement to support backwards compatibility both
>>> submitters suggested implementing a spl_autoload_case_sensitivity()
>>> function. The patch I have attached adds su
Re: [PHP-DEV] Class Access Modifiers
Hello, On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles wrote: > Interesting question. My gut tells me not (as does three years of C# > experience). I’m sure that everyone will have a different opinion on this but > to me it seems taboo that a child class override the visibility of the parent > class. For example, PHP currently does not allow you to override a method > with a lower or higher visibility than the parent – I can’t go from protected > to public or vice versa. Visibility must be maintained throughout the class > hierarchy. > Actually, class properties and methods can have a higher visibility than their parents, just not a lower one. E.g.: You get the following error: Fatal error: Access level to foobar::bar() must be public (as in class baz) in ... --- That said, I wouldn't think that visibility modifiers on classes need to follow the same pattern. In the case of properties and methods, I think the rationale is that child classes should be compatible from an interface standpoint with their parents. That same logic may not transfer to class visibility modifiers. I am certainly no expert, but I'm curious what the use case is for class visibility modifiers? On Wed, Mar 9, 2011 at 7:11 AM, Hannes Landeholm wrote: > Currently I'm forced to use huge internal classes for my framework because dividing them into smaller classes would expose internal behavior to the "outside"... the application layer. > This doesn't necessarily make sense to me. Isn't it the end-developer's problem if they start instantiating classes in weird ways? It doesn't seem the same as having a private method, since in that case the end-developer presumably already has an object instance, and you want to guide them to the correct interface for interacting with it, whereas in an application, one would think that the end-developer wouldn't simply be instantiating classes by themselves all over the place. Chad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Class Access Modifiers
Interesting question. My gut tells me not (as does three years of C# experience). I’m sure that everyone will have a different opinion on this but to me it seems taboo that a child class override the visibility of the parent class. For example, PHP currently does not allow you to override a method with a lower or higher visibility than the parent – I can’t go from protected to public or vice versa. Visibility must be maintained throughout the class hierarchy. I realize that ten thousand people will curse up and down the first time they try to extend an internal class with a public one but good application design should be the real solution. >> Proposal (after five minutes of thought) >> >> >> 1. Public - A class can be instantiated or called statically from >> anywhere. For reasons of backward compatibility a class without any modifier >> would be considered public. >> >> 2. Internal - A class can only be instantiated/called from within the >> same root namespace. If I have a class Core\Mvc\View, only from within a >> class sharing the same root namespace (ex: Core\Html\Textbox) would I be >> able to access the "View" class. >> >> 3. Private - A class can only be instantiated/called from within the >> exact same namespace. Example, class Core\Mvc\View could only be accessed >> from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). >> >> What do people think? I'm not too concerned with the exact three I listed >> above, but more and more I think it would be wise if there were a way to >> restrict the accessibility of classes between namespaces. >> >> Jarrod Nettles >> Really like the general idea and think (IMHO) its RFC worthy, but have a few questions... Would there be any method of overriding the the visibility in a child class?And would the child class inherit the parents visibility? I realise this may seem daft initially but I can think of some instances where this might be useful. James Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f 309.828.1808 This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission. Please consider your environmental responsibility before printing this e-mail
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 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 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
> 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 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,
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 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
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 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
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 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 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 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_shut
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
On 03/08/2011 09:02 AM, Jared Williams wrote: Would pcntl_alarm() work? I think it does. Just hacked up https://github.com/sebastianbergmann/php-invoker but I need to do some more testing to make sure that it actually works the way want it to. Thanks! Sebastian -- Sebastian BergmannCo-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
Re: [PHP-DEV] Class Access Modifiers
>> Proposal (after five minutes of thought) >> >> >> 1. Public - A class can be instantiated or called statically from >> anywhere. For reasons of backward compatibility a class without any modifier >> would be considered public. >> >> 2. Internal - A class can only be instantiated/called from within the >> same root namespace. If I have a class Core\Mvc\View, only from within a >> class sharing the same root namespace (ex: Core\Html\Textbox) would I be >> able to access the "View" class. >> >> 3. Private - A class can only be instantiated/called from within the >> exact same namespace. Example, class Core\Mvc\View could only be accessed >> from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). >> >> What do people think? I'm not too concerned with the exact three I listed >> above, but more and more I think it would be wise if there were a way to >> restrict the accessibility of classes between namespaces. >> >> Jarrod Nettles >> Really like the general idea and think (IMHO) its RFC worthy, but have a few questions... Would there be any method of overriding the the visibility in a child class?And would the child class inherit the parents visibility? I realise this may seem daft initially but I can think of some instances where this might be useful. James -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 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 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 o
Re: [PHP-DEV] Class Access Modifiers
Good Sugesstion. Currently I'm forced to use huge internal classes for my framework because dividing them into smaller classes would expose internal behavior to the "outside"... the application layer. This would solve that problem. ~Hannes On 3 March 2011 18:21, Jarrod Nettles wrote: > Has there been any discussion on access modifiers for classes? I looked > through the existing RFCs and searched through old discussions on the > mailing list but didn't come up with anything. > > Specifically, I think it would be beneficial (for framework developers in > particular) if classes could be marked as public, private, etc. I haven't > really thought through exact definitions on how each modifier would restrict > but here is a use case. > > A developer is working on an object-oriented framework that uses namespaces > and uses classes extensively. He considers many of the classes to be for > internal use only, that is, they will only be used by the internal workings > of the framework core, not by any web application that somebody builds using > his framework. That being the case, the developer would like to restrict > access to certain classes so that they can only be accessed in certain > situations. > > Proposal (after five minutes of thought) > > > 1. Public - A class can be instantiated or called statically from > anywhere. For reasons of backward compatibility a class without any modifier > would be considered public. > > 2. Internal - A class can only be instantiated/called from within the > same root namespace. If I have a class Core\Mvc\View, only from within a > class sharing the same root namespace (ex: Core\Html\Textbox) would I be > able to access the "View" class. > > 3. Private - A class can only be instantiated/called from within the > exact same namespace. Example, class Core\Mvc\View could only be accessed > from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). > > What do people think? I'm not too concerned with the exact three I listed > above, but more and more I think it would be wise if there were a way to > restrict the accessibility of classes between namespaces. > > Jarrod Nettles > Application Developer - Technology > INCCRRA > p 309.829.5327 - f 309.828.1808 > > This e-mail message may contain privileged or confidential information. If > you are not the intended recipient, you may not disclose, use, disseminate, > distribute, copy or rely upon this message or attachment in any way. If you > received this e-mail message in error, please return by forwarding the > message and its attachments to the sender. INCCRRA does not accept liability > for any errors, omissions, corruption or virus in the contents of this > message or any attachments that arises as a result of e-mail transmission. > > Please consider your environmental responsibility before printing this > e-mail >
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
Yes, it's possible to measure the "time left" yourself. However
set_time_limit documentation states that not all time are accounted for when
measuring how long the script can run for. If it's a UNIX system and you're
using system operations/database queries etc there will be a difference
between the time you measure the script has run for and the time PHP has
measured.
And this is only a suitable solution in controlled code like when you're
doing something defined in a loop and can measure the time with regular
intervals. I need it for my framework which can contain any kind of logic,
even logic that uses set_time_limit by itself.
~Hannes
On 9 March 2011 15:52, Thomas Hruska wrote:
> On 3/9/2011 6:56 AM, Hannes Landeholm wrote:
>
>> 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.
>>
>
> I like this. Although, I'd rather the first parameter were in milliseconds
> instead of seconds. This would tell PHP 'x' milliseconds before script
> termination to call the specified function. That function would then have
> the remainder of the time slice to execute cleanup routines and send any
> errors to the user. This approach also doesn't require a whole new
> configuration option in php.ini.
>
>
>
> 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?
>>
>
> This is already possible to do. I do this in WebCron by setting a variable
> with the value of microtime() at the start of execution and figuring out how
> long the script can actually run for. Then, I stop executing a task if
> there are less than a few seconds left on the clock so that there is ample
> time to clean up gracefully. For more information:
>
> http://barebonescms.com/documentation/webcron/
>
> Then I expose a convenience function called WC_GetTimeLeft() to modules and
> tasks that can use it to test to see how much time is left on the clock to
> execute the script. The approach works quite well. As an example, I use
> WC_GetTimeLeft() extensively in my WebCron Site Backup module that can
> backup websites of any size over HTTP/HTTPS.
>
> http://barebonescms.com/documentation/webcron_site_backup/
>
> So, while it can and has been done, it does require a little extra work at
> the start of the script and obviously isn't as accurate as a dedicated
> function in PHP itself would be.
>
> --
> Thomas Hruska
> CubicleSoft President
>
> Barebones CMS is a high-performance, open source content management system
> for web developers operating in a team environment.
>
> An open source CubicleSoft initiative.
> Your choice of a MIT or LGPL license.
>
> http://barebonescms.com/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 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 BergmannCo-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
>> >
>> >
>>
>
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
On 3/9/2011 6:56 AM, Hannes Landeholm wrote:
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.
I like this. Although, I'd rather the first parameter were in
milliseconds instead of seconds. This would tell PHP 'x' milliseconds
before script termination to call the specified function. That function
would then have the remainder of the time slice to execute cleanup
routines and send any errors to the user. This approach also doesn't
require a whole new configuration option in php.ini.
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?
This is already possible to do. I do this in WebCron by setting a
variable with the value of microtime() at the start of execution and
figuring out how long the script can actually run for. Then, I stop
executing a task if there are less than a few seconds left on the clock
so that there is ample time to clean up gracefully. For more information:
http://barebonescms.com/documentation/webcron/
Then I expose a convenience function called WC_GetTimeLeft() to modules
and tasks that can use it to test to see how much time is left on the
clock to execute the script. The approach works quite well. As an
example, I use WC_GetTimeLeft() extensively in my WebCron Site Backup
module that can backup websites of any size over HTTP/HTTPS.
http://barebonescms.com/documentation/webcron_site_backup/
So, while it can and has been done, it does require a little extra work
at the start of the script and obviously isn't as accurate as a
dedicated function in PHP itself would be.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
http://barebonescms.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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 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 BergmannCo-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
> >
> >
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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 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
> >> 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 BergmannCo-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
>
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
I'm personally a fan of errors and well defined return values. Exceptions
doesn't solve any problem unless your problem is that your code is not
enough spaghetti-ish. But I agree with "All fatal errors should be changed
to catchable fatal errors".
~Hannes
On 9 March 2011 15:18, Martin Scotta wrote:
> Fatal error are most dumb feature in the language.
> The are lot of "blind" areas where you don't know if you will ever
> return...
>
> include "file.php";
> new Class();
> call_func();
>
> All fatal errors should be changed to "catchable fatal errors" so
> applications will be able to recover themselves... and if they don't catch
> the error... then die.
>
> it would be nice if all errors could be changed into exceptions.
>
> Martin Scotta
>
>
>
> On Wed, Mar 9, 2011 at 10:56 AM, 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 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 > >
>> > 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 BergmannCo-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
>> >
>> >
>>
>
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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
>> 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 BergmannCo-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
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
Fatal error are most dumb feature in the language.
The are lot of "blind" areas where you don't know if you will ever return...
include "file.php";
new Class();
call_func();
All fatal errors should be changed to "catchable fatal errors" so
applications will be able to recover themselves... and if they don't catch
the error... then die.
it would be nice if all errors could be changed into exceptions.
Martin Scotta
On Wed, Mar 9, 2011 at 10:56 AM, 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 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
> > 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 BergmannCo-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
> >
> >
>
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
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 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
> 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 BergmannCo-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
>
>
