[Phpmyadmin-devel] AJAX error reporting system (catching errors)

[Dieter Adriaenssens]

2013/6/22 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
> On Sat, Jun 22, 2013 at 10:27 AM, Rouslan Placella <rouslan at placella.com> wrote:
>> On 06/22/2013 01:21 AM, Mohamed Ashraf wrote:
>>> On Saturday, June 22, 2013 at 12:49 AM, Rouslan Placella wrote:
>>>> On 06/16/2013 12:59 PM, Mohamed Ashraf wrote:
>>>>> On Wed, Jun 12, 2013 at 9:58 AM, Rouslan Placella
>>>>> <rouslan at placella.com> wrote:
>>>>>
>>>>>> Some of my thoughts are:
>>>>>>
>>>>>> * Try/catch has a performance penalty
>>>>> it is not too big as can be seen here
>>>>> http://jsperf.com/try-catch-performance-overhead
>>>>
>>>> Really? On some browsers it's about 20 times slower on the very
>>>> benchmark that you are linking to!
>>> Really!! That is strange I tested it multiple times and everytime it
>>> showed they are all equal in time. Which test case was 20 times slower?
>>
>> Opera 11 would be one of them. IE 10 is also quite bad, but by a lower
>> magnitude...
>
> the reduction in performance is usually in wrapping the inside of a
> function with try and catch. I was thinking of doing the other way and
> wrapping the functions from outside like this
>
> var temp  = PMA_foo
> PMA_foo = function() {
> try{
> temp.apply(window, arguments);
> } catch(e) {
> my_method(e);
> }
> }
>
> I am thinking of doing this to all global functions starting with PMA_
> and according to the benchmark this should have an equivalent
> performance to the no try catch  performance. also if we don't do
> anything of the sort then we would never get a stacktrace.

Just wondering, if you add try-catch phrases to the current PMA_*
functions, I guess they should be added to future PMA_* functions as
well?

> the javascript in phpmyadmin is just for aesthetics and caching but it
> is not really very processor intensive anyway it is mostly about doing
> things to the page and sending requests to the server and most of the
> heavy lifting is done by jquery itself which I shall not change. The
> benchmark is to show what happens in the extreme case which may be
> problematic in node.js where the js code does heavy lifting and
> performance hits are problematic. however for the simple javascript we
> have, the negligible loss in performance cannot be perceived by the
> end users. but the stack traces we get could significantly better
> their experience in the long run.
>
> I will be using an automated function to add the try and catch at
> runtime so that there would be minimum modification to the codebase
> and it can be easily removed if required.
>
>>
>>>>>> * We need to be able to easily turn off the error reporting feature
>>>>> You can do it simply by setting a config option I have already set it
>>>>> up in the Header.class.php
>>>>>> * Some/most function names in the stack trace are going to be useless as
>>>>>> the production js code is minified.
>>>>>> * The line numbers in the file will not be of much help either, I guess,
>>>>>> unless we change the way that the files are minified (like forcing line
>>>>>> breaks every few hundred characters).
>>>>> since uglified js provides little to no information about the location
>>>>> of the error. what should we do. I checked up on source maps however
>>>>> the browser support is not enough. so what do you think should happen.
>>>>> I think the only way to go is to add try and catch to all the
>>>>> different functions if you need to find out where the error has
>>>>> occured. however adding try and catch statements to the entire
>>>>> codebase will decrease code readability considerably.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Phpmyadmin-devel mailing list
>> Phpmyadmin-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel



--
Kind regards,

Dieter Adriaenssens