Is it OK to perform a mysqli query on a class __destruct function?
I heard somewhere it will not always finish the query or it won't work as expected.
For example:
class stackoverflow{
function a() {
}
function b() {
}
function __destruct() {
//mysqli query here
}
}
Generally, you are better of creating your own method to carry out any work that needs to be done toward the end of the script and call it manually.
The principle reason for this in my view, is error handling.
According to the online documentation:
Attempting to throw an exception from a destructor (called in the time of script termination) causes a fatal error.
This means that should an error arise - for example - in your mysql query, a fatal error will shutdown your script.
a __destruct method may well be useful at times, but better used in situations that only require some simple hard-code, which is tested and not error prone.
Additionally, some servers may change various parameters during the shut-down phase. Such as the working directory.
There's no reason why it shouldn't work as expected. However, it would help if you explained why you wanted to do so in the first place, there may be a better solution than what you have in mind
Related
If I have the following class method:
class ClassA
{
public function MethodA()
{
trigger_error('An error has occurred.', E_USER_ERROR);
}
}
... then what is the accepted way of documenting that it might "throw" (issue) an error using trigger_error() explicitly? The closest I found was to use either #throws, or #exception. Is it possible this behavior should not be documented at all, or instead included in the method description itself?
The reason I ask this question about trigger_error is because I use a custom error logging class which is called by a custom error handler, hence it is convenient to issue runtime errors and output/save them in an organized fashion. Should I just use #see trigger_error or #see ErrorLog (my custom class) instead?
EDIT:
For those wondering about the script flow if an error is triggered: the script will not terminate execution on E_USER_ERROR.
The script will not terminate execution on E_USER_ERROR.
This may be your bigger issue. PHP's error mechanism is rather... primitive. It basically only knows two modes: notify the developer of potential issues by triggering a notice, warning or stern warning (a.k.a. error), or to stop the script by triggering a fatal error. Triggering a (fatal) error yet continuing with the script execution is not really its purpose.
The function should simply be documented informally with "triggers error if X, Y or Z". This typically means "will kill script if X, Y or Z". If you're overriding that behaviour, that's up to you.
Formally documented errors make sense if those errors can be handled in a standardised manner, which is very much what exceptions are. They have formal documentation standards (#throws) and can be handled in flexible ways (try..catch). You really should use exceptions for the purpose you're trying to use errors here.
Is there a way to catch Call to a member function foo() on a non-object in PHP? It does not sound that serious (as far as fatal errors go), but the shutdown function does not seem to be called at all (PHP 5.3, Debian).
Update:
How to prevent such errors is really not the point. Sure, one should check for null whenever that is an expected possibility, but littering every single object member function reference with error checking code would result in bloated and unreadable code. Hunting down the occassional error based on the logs is fine - the problem is that logs are not very useful for fatal errors. Using a shutdown function would solve that nicely, but I can't get it to work with this specific type of error; which seems strange to me, because it is not an error which would leave the PHP interpreter in a particularly messy state.
I hope this does not sound silly - but you should make sure you know what you are working with. Use instanceof or is_object where you need - or fix the source of the problem - why is that variable not an object in the first place?
I suggest to just ensure, that it is an object. Using methods/functions you can use type hints
public function x (myClass $object) {
$object->foo();
}
else you may use is_object(). At the end such a message sounds like there is a bug within you application, that should be fixed before release, or -- if such a situation can occur by design -- verify the type (is_object() (see above) or !is_null($obj) or something like that) before trying to call something, that does not exist.
After taking a look at some old code:
//Nothing like a destructor!!
function destroy() {
settype(&$this, 'null');
}
And called by
$Cache->destroy();
However in PHP 5.3 I get
Deprecated: Call-time pass-by-reference has been deprecated in /blah/-cache-.php on line 154
How should I do this?
Your immediate problem can be met by removing the & in $this, but the whole construction doesn't make sense to me. If it's not plain invalid to destroy $this from within the object's context, it's definitely not good practice.
To destroy an object, a simple
unset($Cache);
will do.
If one wants to execute stuff when the object is destroyed, one should define a destructor in the class. (The comment in your destroy() code says that this is not the point here, though. :)
Just destroy the object like normal.
unset($Cache);
I don't know why they would do that nasty looking mess above. Keep in mind that if the object has pointers in different places you will need to unset all of them - not just that one line. (singletons are an example)
The error you're getting is not related to having a destructor. The error is simply because you've tried to pass $this by reference in a function call.
PHP used to allow this, but in current versions of PHP, if you want to pass something by reference, you should specify it in the function declaration.
Therefore, your function call should look like this:
settype($this, 'null');
(ie without the &). (btw -- the word 'null' in a string??? is that what you meant?)
And if you want to pass by ref, your function should look like this:
function settype(&$object, $secondparameter) {
...whatever the function does...
}
ie with the & in the function parameter.
This rule applies in all cases in PHP. As I said, it has nothing to do with your destructor method, or with it being an object; that's just how you pass by reference in modern PHP.
Now onto the other part of your question: A destructor method.
PHP does allow for an automatic destructor function, written within your class like this:
function __destruct() {
print "Destroying " . $this->name . "\n";
}
If you write this code, the __destruct() method will be called when the object is destroyed. This may or may not be what you want -- depends on how you want it to work. The object will be destroyed when all references to it are unset or come out of scope. If you're passing the object handle around by reference, this may not happen when you expect it to -- ie the object may persist in memory even when you say unset($myobject);. In this case, it may only actually get destroyed when the PHP program finishes running. If this is the case, and you need it to be called sooner than that, you may be fine continuing with the destroy() method you have already, and calling it explicity.
Hope that answers your question.
First of all, this question is purely theoretical. Fact is, whether it's possible or not, it would be terribly bad practice. Having said that, here's my question:
PHP offers the possibility to define custom error handlers via the set_error_handler function. By parsing the error message, it's possible to find out what triggered the error.
I'm interested mostly in 'Call to undefined function' errors. I know its possible to parse the error message to uncover the called function, and this got me thinking.
Would it be possible for the error handler, in case of an Undefined Function, to attempt to include a file (say functions.html.php for all functions starting with a html_ prefix), and then attempt to re-execute the function, plus arguments, that initially triggered the error? And, most importantly, return the function's value in case of success?
In brief without using exception handling you won't be able to recover from the error in the way you described.
There is a way to handle this specifically for undefined functions, however that is to say undefined member functions from an object. This is the __call() method. Basically if you call an undefined method from an object __call() then takes that function call and does whatever you put in the method body see http://php.net/manual/en/language.oop5.overloading.phplink text
It's not really possible to restart the execution where the error occured.
However: there is a system to loading classes on demand, using the __autoload function.
From the manual:-
You may define an __autoload function which is automatically called in case you are trying to use a class/interface which hasn't been defined yet. By calling this function the scripting engine is given a last chance to load the class before PHP fails with an error.
There is more in the PHP manual here: http://php.net/manual/en/language.oop5.autoload.php
I understand the significance of the term 'fatal error', but I want to write a test class like this (disgustingly simplified):
class tester {
function execute() {
if( #$this->tryit() === true ) return true;
return false;
}
function tryit() {
$doesntexist = new noobject();
return true;
}
}
actually I'd have a Test parent class, and then classes would extend it and contain a bunch of methods with a bunch of tests. The parent class would define execute and it would just run every method in the child class (excluding execute of course) and collecting data on which functions pass and which fail.
I want to write tests before I actually write part of my code, but instead of using assert I just want to run every test and generate a list of which functions of which test classes fail. But that means if a test fails it means there was an error -- but I also want to handle instances where I forgot to define a class, etc. Is it possible to do that, while not having the entire script die?
I was thinking that the script would just fail up until the function call with the # in front of it, and then continue, but obviously I was wrong. Is there a workaround?
A fatal error is fatal, and there is nothing you can do about it.
Two ideas of solutions could be :
To test if the method exists before trying to call it ; see method_exists
Or, to run each "test" in a separate processus : this way, if there is a Fatal Error caused by one test, only the "child" process corresponding to that test dies, and the "parent" process, the test launcher, can detect this and consider it as a failure.
Actually, the second solution exists in PHPUnit since version 3.4, if I remember correctly ;-)
Fatal errors cannot be stopped, not even with set_error_handler. However, you can often find another way at the expense of writing more code. For the example method tryit, you can write an autoload function that triggers a non-fatal error or (in PHP 5.3.0) throws an exception, or use class_exists to skip the instantiation of a non-existent class.
Yes and No
You cannot write it so that the code picks up where it left off, after the fatal. However, you can use register_shutdown_function() to continue processing php after the fatal error.
I've written code that checks which kind of fatal error it was and then attempt to fix it before redirecting the user back to the same page, or dying.
register_shutdown_function is excellent for redirecting the user to a 500 error page with a contact form prevalued with the error info. This way I could have the users help me out by opening an issue on my github acct.
I'm guessing you would set up an error handler with the set_error_handler() function that calls into your testing class to report an error, but I'm not entirely sure exactly how you'd implement it.
With PHP 7, you can now try/catch a fatal error.
https://www.php.net/manual/en/language.exceptions.php