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

[Mohamed Ashraf]

On Monday, June 24, 2013 at 4:19 PM, Dieter Adriaenssens wrote:
> 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?
> 
> 

I am using javascript to wrap the code around at runtime. Any new function would be wrapped automatically if I do my job right 
> 
> > 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
> 
> ------------------------------------------------------------------------------
> 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
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20130624/fd6b3bf0/attachment.html>