Back to The tech awesomeness
Table of contents
JavaScript chapters

The article for today.

The snippet:

window.onerror = function(message, url, linenumber) {  
    if (window.XMLHttpRequest) {
        var xhr = new XMLHttpRequest();
        var scripturl = 'http://yourdomain.example.com/log';
        var log = linenumber + message + url;
        xhr.open('POST', scripturl);
        xhr.setRequestHeader('Content-Type', 'text/plain;charset=UTF-8');
        xhr.send(log);
    }
    return true;
}

As a practice asking myself: should it really be used as a solution?

There is a dilemma:
how to handle error with built-in javascript programming language in organisations with multiple concerns from the different groups and the quality as a common cornerstone

Some of the numerous options for solutions:
1 - avoid errors and think about the code is acme state at each even moment of time as of permanent mode
2 - accept errors, search logs during manual testing after automated testing and handle each error as soon as possible
3 - accept errors and send them to server after each one has occurred
4 - accept errors and wait for user feedback
5 - rest easy and wait for critical case to fix
6 - search or research for hidden gem

  1. Avoid errors + testing is fine, until they occur. Not a very practical solution. From the developer point of view this is not a solution in the long run. User point of view is fine with exceptions. Support point of view is rest easy and handle something else. Managers might worry only when the errors occur.

  2. Accepting errors comes in place even with adopted testing practices onboard . But at what extent? Let's handle as soon as possible after log scanning. User point of view starts to be hurting. This solution maybe one of the possible compromises.

  3. Send errors to server. Mainly concerning the link connected. Then server may forward it(or handle by other rules) to managers/testers/developers/... to their tech-emails. With the issue of inbox may become overwhelmed with similar error-emails or even scammed. However this way is quite open for process of assessment whether to fix/or not plus prioritisation by managers/testers/developers or add/remove your group of people from your organisation. This solution may also be one of the possible compromises.

  4. Accept errors and user feedback. Seems like a short-sight solution, but the user happiness or satisfaction may become harsh in feedback. Developers start to feel free comparing to previous points. However this solution is not so agile in a sense.

  5. Rest easy. There is an issue, the user does not see it, if user can work out by their means or ask support or perform the actions in some other way. Devs/testers maybe happy. User maybe frustrated in the easiest form of representation of such UX-status. Rather hard to advocate managers concern of product quality for this approach. Support may struggle.

  6. Search or research for hidden gem. Hidden gem in this case is a concept of a solution already existing or maybe not yet at the point of first search which seems. Long-term oriented, however is not rather practical. Not agile and suitable for most of the organisations. Research price is high per se after early/late fail attempt, the resources still will be used without even a solution. Support is not yet suitable for this type of "undefined"-solution in a constant search.

So at the current point, I still on side of described 2nd or 3rd solution. Each one has pros and cons. Both are not acceptable in a number of other cases. The second solution is rather agile, qualitative, comprehensive and time/resource- consuming, not acceptable in on-demand industries. The third one is more liberate, but not always acceptable in reactive, fault-intolerant industries.

Waiver 1: I does not separate devs/users and/or other groups distinctly in any context, assuming they can change their roles or use the results of each other at any arbitrary point of time. Here it was about shortest trial to think about "concerns vs quality" error handling in javascript context.

Waiver 2: I neither calculate, nor assessed the needed tech resources and produced influence the tech on the virtual environments/natural ecosystems.