How can I customize the error message when a class which implements an interface doesn't contain requested methods?
Actually I get:
Fatal error: Interface function X cannot contain body in Y on line Z
Assuming you can't intercept the error before it happens and throw an exception or trigger a custom error your only chance is trying with register_shutdown_function and try to catch the Fatal error and parse the string that comes error_get_last()['message'] if error_get_last()['type'] is a fatal error.
Notice: that the registered callback passed as shutdown function is called also when the script ends successfully, therefore you have to check if error_get_last is not empty.
Apparently you cannot even walk the register shutdown function path, therefore what you are asking is not possible in PHP.
Related
what i know is spl_autoload_register function is lib function which takes callback function which gets executed when error 'file not found'(fatal) occurs while using new keyword and that include that specific class or rather file.
so my question is how does it handle fatal error being on top of the code if suppose it can handle fatal error.
and my think of error or exception handle is you must know error or exception is that we must know before so that we can include this in the block try,throw, catch.
so my question is how does it catches error being on top of the code.
i am beginner any help appreciated.
thankyou
I am a bit confused about those terms and their exact meaning / handling in PHP:
Exception could be defined like this:
When an error occurs within a method, the method creates an object and
hands it off to the runtime system. The object, called an exception
object, contains information about the error, including its type and
the state of the program when the error occurred. Creating an
exception object and handing it to the runtime system is called
throwing an exception.
Exceptions can be caught and handled.
Fatal Error could be defined like this:
Fatal errors are critical errors - for example, instantiating an
object of a non-existent class, or calling a non-existent function.
These errors cause the immediate termination of the script, and PHP's
default behavior is to display them to the user when they take place.
Fatal errors can not necessarily be caught (they do not throw usual exceptions), otherwise there would be no more specific Catchable Fatal Error.
However how is a Catchable Fatal Error different from a normal Exception? And is it handled the same? Is a catchable fatal error a specific type of exception or not?
Fatal errors can not necessarily be caught (they do not throw usual
exceptions)
Prior to version 7, this was the case. Fatal errors used to stop the script dead in its tracks. However, as of version 7, they're now presented as catchable exceptions. This allows you to gracefully recover from pretty significant issues.
However how is a Catchable Fatal Error different from a normal
Exception?
They both implement Throwable, but with different anchor classes:
Throwable
Error
ParseError
...
Exception
RuntimeException
...
And is it handled the same?
Yep, you can catch them, just like Exceptions.
Is a catchable fatal error a
specific type of exception or not?
Depends on your semantics. A catchable fatal error is an exception but it's not an Exception, if you get my meaning. You can differentiate like this;
// "traditional" exceptions
try {
throw new Foo();
} catch (Exception $e) {
}
// v7 catchable fatal errors
try {
$not_an_object->not_a_method();
} catch (Error $e) {
}
// both
try {
} catch (Throwable $e) {
}
I have need to store a PHP Exception object in a mysql column. It's for an offline error logging system. Usually I would just serialize() the Exception object and be done with it, but half the time, when trying to do that, I get the following error:
Fatal error: Uncaught exception 'Exception' with message
'Serialization of 'Closure' is not allowed'
I am not sure how to get this to work consistently. I will greatly appreciate anyone who has an answer to this problem.
Thanks.
The exception object to be logged contains an instance of Closure class, PHP's implementation of anonymous functions and closure. Apparently anonymous functions cannot be serialized.
You need to investigate your exception classes and see if any of them is supposed to contain them. Normally, exception classes shouldn't have an anonymous function as property.
This reproduces the same error message as your case:
$exception = new Exception('BOO');
$anonymousFunction = function() { echo 'blah'; };
$exception->anonymousFunction = $anonymousFunction;
serialize($exception);
So dig in through your code, your framework's code, your library's code, and try to find out which exception class did have an anonymous function as class property, who assigned them, why - and then you should be able to create a special case for it.
Hope this helps.
http://php.net/manual/en/function.set-error-handler.php
here's the global error handler definition function. you can define a global error handler and make it write the error description to the database.
And the structure of the exception class :
http://php.net/manual/en/class.exception.php
<?php
function some_function($arg) {
if($filter->check_for_safe_input($arg)) {
throw new Exception("Hacking Attempt");
}
do_some_database_stuff($arg);
}
?>
In the above code example, does do_some_database_stuff ever get called if check_for_safe_input fails, or does the exception stop the function running? It's something I've never quite been sure of, and usually I just stick functions like do_some_database_stuff in an else statement to be sure, but this tends to lead to hugely nested functions.
Yes, uncaught exceptions result in fatal errors that stop the execution of the script. So the do_some_database_stuff function will not be called if an exception is thrown. You can read more about exceptions in this article.
Have a look at the PHP manual on exceptions.
When an exception is thrown, code
following the statement will not be
executed, and PHP will attempt to find
the first matching catch block. If an
exception is not caught, a PHP Fatal
Error will be issued with an "Uncaught
Exception ..." message, unless a
handler has been defined with
set_exception_handler().
php.net/exceptions
So yes, the rest of the function is not being executed, a fatal error occurs instead.
If you catch the exception, execution of the script continues in the corresponding catch block, everything "between" the function which throws an exception and the catch block is not executed.
An exception, if not catched, will end script execution.
See the PHP manual chapter on Exceptions
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