[Phpmyadmin-devel] Suggestions on Work of Week-1 | php Error Reporting Project

[Michal Čihař]

Hi Dhananjay

Dne Sat, 10 May 2014 22:30:41 +0530
Dhananjay Nakrani <dhananjaynakrani at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140515/1350c56e/attachment.sig>