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

------------------------------------------------------------------------------
"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