[Phpmyadmin-devel] Suggestions on Work of Week-1 | php Error Reporting Project
Hi Everyone, This week I started developments on my project. I want to take community's opinion on work I've done so far. Look at the commits [0] & [1]. Currently `common.inc.php` does all error handling initializations. All the run time php errors are already being collected in an object of ` PMA_Error_Handler` pointed globally by `$GLOBALS['error_handler']`. Now, to report all errors I have created a separate script named 'common_error_reporting.inc.php' which is intended to be included at the end of all "*relevant*" scripts. Currently it dumps all collected errors in a local-temporary file named "pma_error_log.txt" (which will be removed in next week's work). To demonstrate the working of ` common_error_reporting.inc.php`, I've included that script at the end of ` index.php`. Please have a look at it at [0] & [1]. Is there any better way of doing the same? Please point out if I can improve it any further. If there are no changes required in it then I would do the same for all "*relevant*" scripts. Another doubt I have is about the relevance of scripts. Which scripts should be consider as relevant here?? I am thinking of considering all scripts that are directly called by user/browser. I think error reporting script does not need to be included at the end of class files and such other library files. In my opinion, the error reporting script should be included at the end of all scripts in project root directory and not in any files inside `/libraries/` directory. Am I correct on this? I also found that PMA triggers errors manually (using trigger_error()) for all the missing extensions and to raise other such user warnings. These warnings are also currently collected by error handler. Do we need to report them?? Or should the errors of E_USER_WARNING type just be ignored while sending reports? Please provide your valuable suggestions and do correct me if I am wrong anywhere. If possible do it at the earliest so that I can incorporate them at an early stage. [0]: https://github.com/dhananjay92/phpmyadmin/commit/7bdad8efe33bed52d25e13ca1c0... [1]: https://github.com/dhananjay92/phpmyadmin/commit/b137255bb617f7f00ac4b734d8b... Thanks, Dhananjay Nakrani.
Hi Dhananjay Dne Sat, 10 May 2014 22:30:41 +0530 Dhananjay Nakrani <dhananjaynakrani@gmail.com> napsal(a):
This week I started developments on my project. I want to take community's opinion on work I've done so far. Look at the commits [0] & [1].
I've already commented on the commits, but giving more detailed answer here now.
Currently `common.inc.php` does all error handling initializations. All the run time php errors are already being collected in an object of ` PMA_Error_Handler` pointed globally by `$GLOBALS['error_handler']`.
Indeed, this is true.
Now, to report all errors I have created a separate script named 'common_error_reporting.inc.php' which is intended to be included at the end of all "*relevant*" scripts. Currently it dumps all collected errors in a local-temporary file named "pma_error_log.txt" (which will be removed in next week's work). To demonstrate the working of ` common_error_reporting.inc.php`, I've included that script at the end of ` index.php`. Please have a look at it at [0] & [1]. Is there any better way of doing the same? Please point out if I can improve it any further. If there are no changes required in it then I would do the same for all "*relevant*" scripts.
Another doubt I have is about the relevance of scripts. Which scripts should be consider as relevant here?? I am thinking of considering all scripts that are directly called by user/browser. I think error reporting script does not need to be included at the end of class files and such other library files. In my opinion, the error reporting script should be included at the end of all scripts in project root directory and not in any files inside `/libraries/` directory. Am I correct on this?
I'd just keep the current framework used for displaying the errors (when $cfg['Error_Handler']['display'] is set to true) and extend it to emit information for the error reporter in case there is new error (maybe as JSON data). So I think best place to handle this is to hook into PMA_Footer::getErrorMessages and pass there the data to the browser. The client side then can do the reporting itself (same as it is with the Javascript errors right now).
I also found that PMA triggers errors manually (using trigger_error()) for all the missing extensions and to raise other such user warnings. These warnings are also currently collected by error handler. Do we need to report them?? Or should the errors of E_USER_WARNING type just be ignored while sending reports?
I think we care only about errors raised by PHP, all these E_USER_WARNING are usually just wrong configuration issues. -- Michal Čihař | http://cihar.com | http://phpmyadmin.net
Hi Michal, On Thu, May 15, 2014 at 4:13 PM, Michal Čihař <michal@cihar.com> wrote:
Hi Dhananjay
Dne Sat, 10 May 2014 22:30:41 +0530 Dhananjay Nakrani <dhananjaynakrani@gmail.com> napsal(a):
This week I started developments on my project. I want to take community's opinion on work I've done so far. Look at the commits [0] & [1].
I've already commented on the commits, but giving more detailed answer here now.
Currently `common.inc.php` does all error handling initializations. All the run time php errors are already being collected in an object of ` PMA_Error_Handler` pointed globally by `$GLOBALS['error_handler']`.
Indeed, this is true.
Now, to report all errors I have created a separate script named 'common_error_reporting.inc.php' which is intended to be included at the end of all "*relevant*" scripts. Currently it dumps all collected errors in a local-temporary file named "pma_error_log.txt" (which will be removed in next week's work). To demonstrate the working of ` common_error_reporting.inc.php`, I've included that script at the end of ` index.php`. Please have a look at it at [0] & [1]. Is there any better way of doing the same? Please point out if I can improve it any further. If there are no changes required in it then I would do the same for all "*relevant*" scripts.
Another doubt I have is about the relevance of scripts. Which scripts should be consider as relevant here?? I am thinking of considering all scripts that are directly called by user/browser. I think error reporting script does not need to be included at the end of class files and such other library files. In my opinion, the error reporting script should be included at the end of all scripts in project root directory and not in any files inside `/libraries/` directory. Am I correct on this?
I'd just keep the current framework used for displaying the errors (when $cfg['Error_Handler']['display'] is set to true) and extend it to emit information for the error reporter in case there is new error (maybe as JSON data). So I think best place to handle this is to hook into PMA_Footer::getErrorMessages and pass there the data to the browser. The client side then can do the reporting itself (same as it is with the Javascript errors right now).
Yes, indeed that would be an easier way. I looked for the code relating to it. I found that PMA_Footer::getErrorMessages() writes a div element with as 'pma_errors' its id. I found that div to be present in response of index.php. But I could not find that div in the responses generated by other scripts which are executed when user clicks on any of the tabs (Database, SQL, Import, Export etc.). I also looked inside the data._errors in the AJAX.responseHandler() [0]. Is there anywhere else I should be looking instead??
I also found that PMA triggers errors manually (using trigger_error()) for all the missing extensions and to raise other such user warnings. These warnings are also currently collected by error handler. Do we need to report them?? Or should the errors of E_USER_WARNING type just be ignored while sending reports?
I think we care only about errors raised by PHP, all these E_USER_WARNING are usually just wrong configuration issues.
-- Michal Čihař | http://cihar.com | http://phpmyadmin.net
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
[0] : https://github.com/phpmyadmin/phpmyadmin/blob/master/js/ajax.js#L285 Regards, Dhananjay Nakrani.
Hi Dne Fri, 16 May 2014 04:46:03 +0530 Dhananjay Nakrani <dhananjaynakrani@gmail.com> napsal(a):
Yes, indeed that would be an easier way. I looked for the code relating to it. I found that PMA_Footer::getErrorMessages() writes a div element with as 'pma_errors' its id. I found that div to be present in response of index.php. But I could not find that div in the responses generated by other scripts which are executed when user clicks on any of the tabs (Database, SQL, Import, Export etc.). I also looked inside the data._errors in the AJAX.responseHandler() [0]. Is there anywhere else I should be looking instead??
It's IMHO included every time whole page (or rather whole main panel) is being loaded. So for example when you switch the tabs. It is not loaded when only part of content is being loaded. Anyway this should be good enough. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
participants (2)
-
Dhananjay Nakrani -
Michal Čihař