[QA] Investigate logging common JavaScript exceptions

[Željko Filipin]

I remember doing this for a client while I was a freelancer, but I do not
remember the details. As far as I remember, it was not elegant, but doable.
I think this would be a great topic for a hackathon. ;)

Feel free to add me to cc if somebody creates a phab ticket.

Željko

On Tue, Feb 24, 2015 at 11:14 PM, Jon Robson <jrobson at wikimedia.org> wrote:

> I agree that this probably needs something different to EL.
>
> I wonder is if the browser tests can log any JavaScript console errors
> it encounters during test runs somewhere. This would be added
> protection for us to prevent errors leaking into production. I've
> cc'ed QA in case they have any ideas about that.
>
>
> On Tue, Feb 24, 2015 at 2:53 AM, Sam Smith <samsmith at wikimedia.org> wrote:
> > Hey folks,
> >
> > The WikiGrok team committed to the "Investigate logging common JavaScript
> > exceptions" spike [0] and decided that the outcome should be an email
> thread
> > (and, presumably, a ticket after we've hashed this out).
> >
> > Here goes nothing…
> >
> >> We get various errors such as Error: Module not found: toast Error:
> Module
> >> not found: toast
> >> When these occur it would be good to somehow log this to catch
> dependency
> >> problems.
> >> In theory EventLogging should be able to handle this.
> >
> >
> >> 1. Is this a good idea?
> >
> >
> > Logging errors to something that isn't an error log?
> >
> > That aside, I don't think logging errors directly to EL is a good idea,
> > particularly when we don't know the frequency at which they happen.
> >
> >> 2. Is it possible?
> >
> >
> > Sure. See GlobalEventHandlers.onerror [1].
> >
> >> 3. How would we do it?
> >
> >
> > I would advise against logging events directly. Define an API for
> reporting
> > client-side errors that may or may not use EL as a backend, which we can
> > change as requirements change without affecting clients. Flexibility it
> > great, but, more importantly, we'd get control: we could throttle the
> number
> > of errors being logged to EL if something nasty sneaks into production
> (or
> > has already snuck in) and we could deduplicate errors if necessary.
> >
> > So: install an onerror event handler, report the error via the API, and,
> > whenever possible, tell the user that something has gone wrong and that
> > we've made a note of it.
> >
> > –Sam
> >
> > [0]
> >
> https://trello.com/c/wuMIhyyc/6-spike-investigate-logging-common-javascript-exceptions-2-hours
> > [1]
> >
> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror
>
> _______________________________________________
> QA mailing list
> QA at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/qa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20150225/45acfd25/attachment.html>