博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
How can we listen for errors that do not trigger window.onerror?
阅读量:7193 次
发布时间:2019-06-29

本文共 2286 字,大约阅读时间需要 7 分钟。

 

原文: 

window.onerror is triggered whether it was a syntax or runtime error.  has lists of what error events it will and will not catch.

Could you please provide a small code example to show how we can listen for such errors? Can we listen for SyntaxError too?

For a small code example to show how we can listen for such errors:

      

running this example in your browser will pop up an alert message similar to this:

JavaScript error: SyntaxError: missing ) after argument list on line 26 for page_url

In the above example: window.onerror = function(message, url, linenumber), the arguments are:

  1. message: the error message (DOMString)
  2. url: the URL of the file containing the error (DOMString)
  3. linenumber: the line number where the error occurred (unsigned long)

If you run the same example by putting var x=document.getElementById("demo").value; instead of the code with syntax error(as i have shown in the example), it will also be caught by the window.onerror() function and will show an alert message similar to this:

JavaScript error: TypeError: document.getElementById(...) is null on line 25 for page_url

window.onerror acts something like a global try/catch block, allowing you to gracefully handle() uncaught exceptions you didn’t expect to see:

  • uncaught exceptions

    1. throw "some messages"
    2. call_something_undefined();
    3. cross_origin_iframe.contentWindow.document;, a security exception
  • some more compile error

    1. <script>{</script>
    2. <script>for(;)</script>
    3. <script>"oops</script>
    4. setTimeout("{", 10);, it will attempt to compile the first argument as a script

But two major issues described  nicely:

  1. Unlike a local try/catch block, the window.onerror handler doesn’t have direct access to the exception object, and is executed in the global context rather than locally where the error occurred. That means that developers don’t have access to a call stack, and can’t build a call stack themselves by walking up the chain of a method’s callers.

  2. Browsers go to great lengths to sanitize the data provided to the handler in order to prevent unintentional data leakage from cross-origin scripts. If you host your JavaScript on a CDN (as you ought), you’ll get “Script error.”, “”, and 0 in the above handler. That’s not particularly helpful.

edit

转载地址:http://emtkm.baihongyu.com/

你可能感兴趣的文章
zabbix server 端安装
查看>>
40. Combination Sum II - Medium
查看>>
第七周作业
查看>>
洛谷——P2958 [USACO09OCT]木瓜的丛林Papaya Jungle
查看>>
top Universities in Mechanical Engineering
查看>>
ios之UIScrollView
查看>>
DO,DTO和VO的使用
查看>>
C++函数重载,重写,重定义
查看>>
Babelfish
查看>>
一:Newtonsoft.Json 支持序列化与反序列化的.net 对象类型;
查看>>
jquery特效 商品SKU属性规格选择实时联动
查看>>
vue之后台管理系统遇到的几个痛点
查看>>
使用keytool生成ssl密钥文件keystore和truststore
查看>>
Elastic Search Java Api 创建索引结构,添加索引
查看>>
Password
查看>>
文件操作练习之统计目录大小
查看>>
在vs2010 .net 4.0 引用dll .net 2.0(转)
查看>>
【JAVA练习】- 接收三个班各四个学员的成绩,算平均分
查看>>
Python3新特性 类型注解 以及 点点点
查看>>
【解决】node的环境变量
查看>>