自动向开发人员报告 javascript 错误
与大多数生产环境一样，我们设置了一些设置，以便在 Web 应用程序出现错误时向我们发送通知。问题当然是这仅涵盖服务器端的错误。
我向社区提出的问题是：对于客户端错误，尤其是 JavaScript 中的错误，您正在采取什么措施？
那么其他服务质量问题（例如处理速度慢以及可能由客户端计算机引起的其他问题）又如何呢？
As most production environments we have setup something to send us a notification if there is an error in our web application. The problem is ofcourse that this only covers errors on the server side.
My question to the community is: What are you doing about client side errors, especially in javascript?
And what about other quality of service issues, such as slow processing and other things that might be due to the client machine?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用处理程序内的 window.onerror 事件处理客户端 JavaScript 错误
，向服务器端错误挖掘器发出 Ajax 请求并记录错误。
http://www.javascriptkit.com/javatutors/error.shtml
窗口。并非所有浏览器都支持 onerror，jQuery 可以用自己的事件处理程序来填补空白：window.onerror 和 jQuery(window).error 应该就足够了
You can handle client side JavaScript errors with window.onerror event
Inside the handler make an Ajax request to your server side error miner and log the error.
http://www.javascriptkit.com/javatutors/error.shtml
Hovewer window.onerror is not supported in all browsers, jQuery can fill up the gap with its own event handler: a combination of window.onerror and jQuery(window).error should suffice
对于客户端的 JavaScript 错误，您无能为力。您可以捕获
window.onerror并将其用于 AJAX 报告，但是：(a) WebKit 或 Opera 不支持它。要捕获所有错误，您必须将每个直接执行、事件和超时入口点包装在
try { ... }中，这非常混乱，并且提供的信息比还要少。 onerror 处理程序。(b) 您可能会被错误报告淹没，而您却无能为力，并且由于缺乏信息而几乎无法进行调试。您也许能够在仅由您认识的客户访问的应用程序上逃脱惩罚，但在公共访问站点上，许多错误都是虚假的。由以下因素引起的问题：
与托管脚本或 AJAX 的站点的连接失败或被防火墙阻止；
意外的安全设置（浏览器可以选择任意阻止许多接口）；
损坏的浏览器插件、类似 GreaseMonkey 的脚本、过滤代理和伪造的“互联网安全”工具会扰乱您的代码；
损坏的浏览器插件
行为奇怪的不受支持的代理，例如移动浏览器（尤其是令人震惊的 IEMobile）以及自动浏览器机器人（如果它们有访问权限）；
许多错误是由广告等第三方内容（如果有）引起的。
许多
同样，对于可以直接联系遇到问题的任何用户的有限使用应用程序，它可能有用，但对于公众使用的网站来说，它是行不通的。
最好使用“渐进增强”来确保您的应用程序在 JavaScript 失败时仍然可以工作。
There's not a great deal you can do about JavaScript errors at the client end. You can trap
window.onerrorand use it to AJAX a report back, but:(a) it's not supported in WebKit or Opera. To catch all errors you would have to wrap every direct-execution, event and timeout entry point in a
try { ... }, which is very messy and gives you even less information than theonerrorhandler.(b) you will likely be swamped with error reports you can't do anything about, with little debugging possible due to lack of information. You might be able to get away with it on an application that is only accessed by customers you know, but on a public-access site, a lot of errors will be spurious. Stuff caused by factors like:
connections to sites hosting scripts or AJAX failing or being blocked by firewalls;
unexpected security settings (browsers have options to block many interfaces arbitrarily);
broken browser add-ons, GreaseMonkey-like scripts, filtering proxies and bogus “Internet Security” tools messing with your code;
unsupported agents that behave oddly, like mobile browsers (especially the appalling IEMobile) and, if they have access, automated-browser bots;
many errors caused by third-party content like adverts, if you have any.
Again, for a limited-use application where you can directly contact any user who is experiencing problems, it might be of use, but for a site used by the general public it's a non-starter.
It's best to use ‘progressive enhancement’ to ensure that your application still works when JavaScript fails.