如何优雅处理前端异常？

随着行业对于用户体验的重视，前端异常处理这块也被重视起来了。像以前，很少有网站管你前端是否会出现异常的，但现在较大的网站都会收集前端的异常，然后上报到服务端。

所以前端异常处理分两部分：异常捕获 + 异常上报。我们来一一看下。

1、异常捕获

各主流开发语言都是用 try... catch .. 来捕获异常的，当然前端JavaScript也不例外了。最简单的代码如下：

try { ... }catch(e){console.log(e);}

我们虽然可以用 try...catch...来对异常进行处理，但是也存在个问题：代码会越来越复杂，越来越臃肿，而且这种方法只适合片断代码的异常捕获，全局异常捕获很麻烦。

于是有一个更好的方法。

window.onerror 它就提供了全局异常监听的功能，不光光提供了错误代码的行号、还提供了借误信息，非常有利于我们对异常进行精确定位。

2、异常上报

当我们捕获到了前端异常后，就需要把异常上报到后台服务器了，我们一般通过Ajax来提交。在上报时我们为了减轻后端压力，所以建议前端若异常是相似的，只上报1次处理。

经过以上的处理，当前端出现异常后，我们可以实时通知程序员进行核验修复。

前端代码写成怎么样才能达到上线的标准？一个简单的页面后端能用吗？

前端代码写成怎么样才能达到上线的标准？标准有以下几点：

一、代码简洁、没有垃圾代码，符合W3C标准；

二、与UI设计图相符；

三、支持各端浏览器，浏览均正常，兼容性好；

四、没有外部引用文件，都在本地引用；

五、我认为达到以上4点就具备了上线的标准；

关于你的第二个问题，一个简单的页面后端能用吗？可以用的，只要在页面源码中注明了各段代码说明，后端程序员就可以看明白。

如有其它问题也欢迎与我交流，也可以在下方评论区留言。

UI和测试员说通过了。

如何看待某些领导让测试把所有bug都指给前端？

因为领导不相信你的专业技术水平，在前端和后端都可以发现网络中的bug。bug是网络中及电脑出现错误的代名词。可以理解为网络中的出现的bug电脑系统里的隐藏着的，一些未被发现的缺陷或者问题未处理好。

所以，领导喜欢有专业技术的人。发现问题，理所当然地交给或者提供有水平的信息开发技术工程师呀。如果你的水平相当，此时领导即便是你在前端或者后端呀，照样给你，这充分说明你脑筋不够用。在一些大公司，网络系统可能是由前端团队和后端团队共同开发出来的，因此在分配bug的时候，不同功能模块的bug一般都会指派给对应的负责团队乃至于个人水平相当高的技术人员来处理。通过这些技术人员的快速操作，可以尽快找到bug的发生根源，如果能尽量提供有价值的信息给开发人员，来缩小定位范围及时间。如果能够直接协助定位到bug出在哪里，那么开发人员将更容易去fix掉bug，从而降低了测试和开发之间的沟通成本，提高了工作效率。

另外，从一个人处理bug的水平，从侧面也能体现测试人员具备了较高的技术专业性，而不是只会一点点，个人形象在项目团队中体现的淋漓尽致。

谢谢邀请！

作为一名IT行业的从业者，我来回答一下这个问题。

首先，从应用的角度来看，当软件产品出现bug的时候，通常都是在前端呈现的，而按照历史经验来看，虽然很多bug是后端导致的（实际上大部分bug都是后端的），但是通过前端来推动后端进行bug调整也会相对比较方便，所以一部分技术负责人最常见的做法就是把所有的bug都指给前端，然后让前端去推动bug的调整。

对于前端开发人员来说，在接收到测试bug的时候，通常需要完成三件事，其一是梳理业务逻辑，判断是否出现接口调用错误；其二是分析调用参数，判断是否出现参数提供不全等问题；其三是梳理呈现端代码，判断是否出现数据呈现不完整的问题。按照历史经验分析，当前端完成bug分析之后，基本上就会确定该bug是属于哪一部分的问题。

测试人员把测试bug推给前端开发人员还有两方面好处，其一是前端开发人员往往对于业务逻辑有比较直观的了解，所以在进行bug调试的时候可以有一个相对全面的分析，而后端开发人员通常是进行数据流处理，在定位bug方面往往还需要前端程序员的配合，其二是前端开发人员往往是推动版本迭代的重要力量，实际上很多软件产品的迭代都是前端在推着后端走，这也是一个比较普遍的现象，尤其是一些中小型的互联网产品。

最后，对于开发团队的负责人来说，往往更关注于解决问题的速度，把bug推到前端通常能够更快速地完成bug修复，这是比较重要的原因。

我从事互联网行业多年，目前也在带计算机专业的研究生，主要的研究方向集中在大数据和人工智能领域，我会陆续写一些关于互联网技术方面的文章，感兴趣的朋友可以关注我，相信一定会有所收获。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言，或者私信我！