I've got a test script - test1.php:
echo "2";
include_once("api_class.php");
echo "3";
$objAPI = new API();
echo "4";
api_class.php has:
<?php
class API extends DATABASE
{
...
}
?>
However, when I access test1.php, I see only:
23
What am i doign wrong?
You didn't get the class source pasted in, but something must be wrong with your syntax. Add the following line to the top of your file and it will output verbose error messages that should point you in the correct direction.
error_reporting(E_ALL);
Most likely, there is an error in api_class.php, more specifically in the API constructor and it is failing. And you have debug/error messages turned off in PHP.
Either turn debug/error messages display on or check your server logs to find the error message.
I 'd guess that the API class expects to establish a database connection (maybe configured by constructor parameters?) and calls die if it cannot. Which is probably what happens when you try to construct a new API.
Related
I'm getting this error when trying to resume a Speech to Text operation.
Google\Protobuf\Internal\GPBDecodeException: Error occurred during parsing: Class google.cloud.speech.v1.LongRunningRecognizeMetadata hasn't been added to descriptor pool in Google\Protobuf\Internal\Message->parseFromJsonStream()
What I'm doing is starting the longrunning operation and storing the name. Later I'm creating a separate page with the status of the operation based on the name I stored previously.
This is what I'm using to try and get the operation status
$speechClient = new SpeechClient();
$operationResponse = $speechClient->resumeOperation($record->operation_name, 'longRunningRecognize');
Is it possible to do something like this?
This took me way too long to figure out for such a simple fix, but here you go.
Put this line before calling resumeOperation:
\GPBMetadata\Google\Cloud\Speech\V1\CloudSpeech::initOnce();.
I think this is a bug within the SDK, but considering their docs say the client libraries are in Alpha, it makes sense.
A longer explanation (since it took me so darn long, and I know I'll find my SO answer in the future if I run into this problem again):
The DocBlocks above the SpeechGapicClient::longRunningRecognize() method show an alternative to blocking polling with $operation->pollUntilComplete()
// start the operation, keep the operation name, and resume later
$operationResponse = $speechClient->longRunningRecognize($config, $audio);
$operationName = $operationResponse->getName();
// ... do other work
$newOperationResponse = $speechClient->resumeOperation($operationName, 'longRunningRecognize');
while (!$newOperationResponse->isDone()) {
// ... do other work
$newOperationResponse->reload();
}
if ($newOperationResponse->operationSucceeded()) {
$result = $newOperationResponse->getResult();
// doSomethingWith($result)
} else {
$error = $newOperationResponse->getError();
// handleError($error)
}
Everything works great if you call resumeOperation() on the same operation returned by the longRunningRecognize() method. If you try to resume in a separate request, as you and I did, we get the error you mentioned above.
The difference is, the longRunningRecognize() method creates a request (LongRunningRecognizeRequest) which is executed whereas resumeOperation() is pretty straight forward and doesn't need to combine request parameters for sending to Google.
The difference here is, the constructor of the LongRunningRecognizeRequest calls \GPBMetadata\Google\Cloud\Speech\V1\CloudSpeech::initOnce(); which sets up the needed speech descriptors.
I hope this helps!
I had a very similar issue, trying to get information about an operation (getOperation):
Google\Protobuf\Internal\GPBDecodeException
Error occurred during parsing: Class google.cloud.speech.v1p1beta1.LongRunningRecognizeMetadata hasn't been added to descriptor pool
As #stevenwadejr already answered correctly, this can be solved by calling initOnce() before the call.
<?php
use Google\Cloud\Speech\V1p1beta1\SpeechClient;
use GPBMetadata\Google\Cloud\Speech\V1P1Beta1\CloudSpeech;
$client = new SpeechClient();
// This line is required. It adds LongRunningRecognizeMetadata and others to the pool of recognized classes
CloudSpeech::initOnce();
// Now, I can get the operation without raising an exception
$operation = $client->getOperationsClient()->getOperation('1234567890123456789');
You can check file \vendor\google\protobuf\src\Google\Protobuf\Internal\AnyBase.php function unpack(). Without the initOnce command the pool variable did not have the fully_qualifed_name (google.cloud.speech.v1p1beta1.LongRunningRecognizeMetadata) in the $proto->proto_to_class array.
First of all, if it's relevant, this is in a session handler. This function is the one that writes to the database and is passed to session_set_save_handler along with my other functions like this
session_set_save_handler('sess_open', 'sess_close', 'sess_read', 'sess_write', 'sess_destroy', 'sess_gc');
I have this chunk of code...
$qid = "select count(*) as total
from zen_sessions
where sesskey = '" . $key . "'";
if(!class_exists('DB'))
require_once dirname(dirname(__FILE__)).'/class/DB.class.php';
var_dump(new DB()); //this is line 109
$total = DB::select_one($qid);
the conditional and var_dump are for testing. Oddly enough sometimes it works fine while others it gives me an error:
Fatal error: Class 'DB' not found in /path/to/file/session_functions.php on line 109
I cannot figure how this wouldn't crash at the require instead of the var_dump and why only sometimes?
Thanks in advance for any insight.
edit-- response to comment/question:
The result of the following code
var_dump(class_exists('DB', false));
var_dump(is_file(dirname(__DIR__).'/class/DB.class.php'));
is:
bool(false) bool(true)
before trying to require it and the same result after the require(or true true when it doesn't give me an error)
Looks something like:
bool(true) bool(true) object(DB)#3 (0) { }
The previous code chunk is the result about once out of every 5 page loads while the error is the result the other 4.
Edit2 -- new findings.
Even more curious is according to the manual I should never see these debugging statements or errors
Note:
The "write" handler is not executed until after the output stream is
closed. Thus, output from debugging statements in the "write" handler
will never be seen in the browser. If debugging output is necessary,
it is suggested that the debug output be written to a file instead.
Edit 3 - A Note for clarity:
The DB class Should have been autoloaded(and is everywhere else in the application) the class_exists and require are simply there for testing purposes.
Edit 4 - Stack trace
I decided to try and throw an exception when the class isn't found to see the stack trace, this is what I get
Fatal error: Uncaught exception 'Exception' with message 'DB Class Not Found.'
in /path/to/file/session_functions.php:108
Stack trace: #0 [internal function]: sess_write('074dabb967260e9...', 'securityToken|s...')
#1 {main} thrown in /path/to/file/session_functions.php on line 108
The only thing that I can think of that may be causing this, is from a notice in the PHP docs for session_set_save_handler:
Warning
Current working directory is changed with some SAPIs if session is closed in the script termination. It is possible to close the session earlier with session_write_close().
From what you are experiencing, I am guessing the current working directory is changed, so require_once doesn't find the file.
I would try adding session_write_close(); to somewhere in your function and see if that fixes it.
Admittedly, not sure why is_file would return true in this case, but maybe worth a shot.
Even though I can not be sure, but I bet that the error is somewhere else and it's just projecting itself as you've described it.
In order to test and debug your code, you need to use a debugger like PDT. But then the problem is that you need to debug a part of your code that is out of debugger's reach, the session writer! To overcome this problem you can use session_write_close. You can put it somewhere at the end of your bootstrap or if you don't have one, you can do it like this:
<?php
function shutdown_function()
{
session_write_close();
}
register_shutdown_function('shutdown_function');
Then by setting a break point, you can start debugging your session code from here. Let me know if I win the bet.
try:
$save_handler = new DB();
session_set_save_handler($save_handler, true);
then map read, write, etc functions inside your class. i faced a similar issue(bizarre random errors about a class not being found) implementing another user's custom save handler workaround for HHVM with redis, and this is how i fixed it. if you are using HipHopVirtualMachine (or possibly some other type of JIT compiler or app cache), sometimes your project can cache some functions without updating, producing odd errors like this. usually a restart of the fastcgi daemon and adding white space to one of your files is enough to force it to re interpret your project.
This is a bit of a long shot, but I figured I'd ask anyway. I have an application that has web-based code editing, like you find on Github, using the ACE editor. The problem is, it is possible to edit code that is within the application itself.
I have managed to detect parse errors before saving the file, which works great, but if the user creates a runtime error, such as MyClass extends NonExistentClass, the file passes the parse check, but saves to the filesystem, killing the application.
Is there anyway to test if the new code will cause a runtime error before I save it to the filesystem? Seems completely counter-intuitive, but I figured I'd ask.
Possibly use register_shutdown_function to build a JSON object containing information about the fatal error. Then use an AJAX call to test the file; parse the returned value from the call to see if there is an error. (Obviously you could also run the PHP file and parse the JSON object without using AJAX, just thinking about what would be the best from a UX standpoint)
function my_shutdown() {
$error = error_get_last();
if( $error['type'] == 1 ) {
echo json_encode($error);
}
}
register_shutdown_function('my_shutdown');
Will output something like
{"type":1,"message":"Fatal error message","line":1}
Prepend that to the beginning of the test file, then:
$.post('/test.php', function(data) {
var json = $.parseJSON(data);
if( json.type == 1 ) {
// Don't allow test file to save?
}
});
Possibly helpful: php -f <file> will return a non-zero exit code if there's a runtime error.
perhaps running the code in a separate file first and attach some fixed code on the bottom to check if it evaluates?
Common handler i used
<?php
function error_msg($err_type,$err_msg,$err_file,$err_line)
{
$fh=fopen("error/errorlog.txt","a");
$date1=date("Y-m-d H:i:s");
$er="
===============================================================================================================
"."
Error: Type: ".$err_type."Message: ".$err_msg."ErrorFile: ".$err_file."Errorline: ".$err_line."Time: ".$date1.
"
===============================================================================================================
";
fwrite($fh,$er);
fclose($fh);
}
set_error_handler("error_msg");
?>
These codes Log error perfectly. Since i am using framework i cant use this codes. so i am using KLogger. KLogger perfectly logs my error but it also display error in front screen to user.
How to log error using KLogger If any one use this KLogger Help me how to use with simple examples.
Just do something like:
require_once 'KLogger.php';
$log = KLogger::instance('/var/log/');
$log->logInfo('Returned a million search results');
$log->logFatal('Oh dear.');
# Output will log to the path you specified, at log_[current-date].txt
It's crazy simple. Read the docs at GitHub
PS, I wrote KLogger.
I would like to be able to discard a partially rendered page and show an error page in PHP.
I already know about set_error_handler(), but it can only trap certain types of errors. I would like to know how to show an error page when an error type which can't be trapped by set_error_handler() is raised.
Unfortunately, it seems that the following code, when run with PHP 5.3.2 on Apache 2.2, doesn't do what I would expect it to do:
<?php
// Start the output buffer
ob_start();
// Output something into the buffer.
// I only want this to be displayed if I call one of the
// ob_flush functions or echo the buffer myself later.
echo "yep";
// Call a function I know not to exist in order to raise
// an error which cannot be trapped by set_error_handler()
// and would, if display_errors was On, output "Fatal
// error: Call to undefined function fwee()..."
function_which_does_not_exist();
// This will never be executed.
$out = ob_get_clean();
The output of the script is:
yep
Whereas I would expect it to output nothing (or spew error info and only error info if display_errors() is on).
I have confirmed using LiveHTTPHeaders that PHP 5.3.2 does send a 500 error to the browser when display_errors is off (and a 200 when it's on) using the version of apache supplied by MacPorts, but it only ever spits 200s when using PHP 5.3.1 on XAMPP.
I tried setting ErrorDocument 500 "test" in the apache configuration (confirmed to be working by doing the same for 404) but PHP never shows the custom error, even when the entire contents of the script is just header('HTTP/1.1 500 Internal Server Error');
I'm not sure what else to do to make sure a partially rendered page is replaced with a simple error.
I can also confirm that this happens in the Yii framework. If I edit the view for the "about" page in the blog demo to have a line which reads <?php echo function_which_does_not_exist() ?>, I get a partially rendered page.
You could pass ob_start the name of a callback function, that is executed before the output is flushed on ob_get_clean().
This callback function seams to be executed even if an error occured on the page.
This way you could do something like this:
<?php
$endReached = 0;
function outpu_cb($buffer) {
global $endReached;
if ($endReached) return $buffer;
else return 'Your error message';
}
// Start the output buffer
ob_start('outpu_cb');
// Output something into the buffer.
// I only want this to be displayed if I call one of the
// ob_flush functions or echo the buffer myself later.
echo "yep";
// Call a function I know not to exist in order to raise
// an error which cannot be trapped by set_error_handler()
// and would, if display_errors was On, output "Fatal
// error: Call to undefined function fwee()..."
function_which_does_not_exist();
// This will never be executed.
$endReached = 1;
echo ob_get_clean();
?>
I think the only right way to do this is by using correct output buffering, than you don't have to rely on specific webserver or browser behaviour.
Best you'd use a MVC framework to handle this for you. All output is buffered until all systems are go, so when an error occurs you can take another route, clear the current buffer and display some nice error message.
You can also use the ob_*() family of functions.
You have to call ob_start() as the very first thing in your script (well, before any output is generated)
Install an error_handler to fetch errors
When an error occured, clean the buffer and re-route your app logic to display some nice userfriendly error message
If your talking about E_FATAL or other such errors yes you can catch them with a custom error handler using set_error_handler().
All you need to add is a shutdown function.
// Set the error handler
set_error_handler(array('error', 'handler'));
// Catch E_FATAL errors too!
register_shutdown_function(array('error', 'catch_fatal'));
// Set the exception handler
set_exception_handler(array('error', 'exception'));
// Manually return a new exception
function catch_fatal()
{
if($e=error_get_last())Error::exception(new ErrorException($e['message'],$e['type'],0,$e['file'],$e['line']));
}
Take a look at http://micromvc.com or http://kohanaphp.com/ to see how it's done.
An old question, but for the record I'd suggest avoiding this issue rather than handling it.
My own approach is to build the response in a response object rather than echoing it as you go along, and only echo the output once the full response has been processed without error. This requires a template system that parses your template and builds your response into a string, in contrast to a classic PHP template which echoes output from your placeholders.
This way you entirely avoid PHP's crufty management of the output cache in error states.