在开发项目中,发送请求的代码中,我们通常都使用try将逻辑代码进行包裹,如果语法错误或者请求错误的话,会在catch中抛出,然后再进行其他错误,在面试的时候,被问到怎么将try catch注册到全局中,避免每次都需要包裹,使代码过于冗余,想问一下如何实现,两种方式的优缺点
在开发项目中,发送请求的代码中,我们通常都使用try将逻辑代码进行包裹,如果语法错误或者请求错误的话,会在catch中抛出,然后再进行其他错误,在面试的时候,被问到怎么将try catch注册到全局中,避免每次都需要包裹,使代码过于冗余,想问一下如何实现,两种方式的优缺点
13 回答13.1k 阅读
8 回答3k 阅读
3 回答1.6k 阅读✓ 已解决
2 回答5.3k 阅读✓ 已解决
5 回答1.6k 阅读
7 回答2.3k 阅读
3 回答2.4k 阅读✓ 已解决
怎么全局注册不知道,但我遇到过一个坑比用
window.onerror=function(){return true;}
屏蔽了所有的报错,仅仅是为了交付的时候不让甲方看到控制台有报错 …… 那么顺着这个思路可以将所有的脚本报错都集中到这个函数里,然后识别所需处理的错误再进行处理就可以了。一个优点就是写着简单。缺点有点多:1. 其他的所有try catch
都没用了(直接在控制台抛错是可以catch
的,但这没有实际用途);2. 跨域脚本需要允许跨域不然不知道报错的细节;3. 貌似还有兼容性的问题。上面一个是真·通用的错误拦截方案,针对
HTTP
请求,有一种思路就是重写请求相关的API
,大致需要重写XMLHttpRequest.prototype.error
、XMLHttpRequest.prototype.onerror
、XMLHttpRequest.prototype.addEventListener
、window.fetch
,优点就是不影响其他错误的正常抛出,一个缺点就是需要写的地方太多了(我可能还没有列完整,比如还有ActivexObject
)。如果全局使用了
axios
的话,就可以通过重写其相关方法或者添加拦截器的方式拦截HTTP
请求的错误 ,优点还是写得少,缺点就是只能针对axios
实现,不过在实际应用中又推荐这种方法,因为一个(没有历史包袱的)项目的技术选型定下来了之后应该不太会变动,写第一次就可以了。