try与catch语句,try-catch语句的功能与用法

　　本文带你了解Javascript的try catch语句，并介绍try catch语句的两个功能。希望对你有帮助！

　　程序自顶向下执行，执行路线可以通过一些控制语句来改变。在控制语句的影响下，程序的最终执行路径就是控制流。

　　js中的控制语句包括if、for、while、try catch等。所有这些都会改变节目的走向。

　　程序操作数据，随着程序的运行而变化的数据，也就是控制流的进度，称为数据流。

　　显然，数据流依赖于控制流，程序分析中的数据流分析也需要先做控制流分析。

　　例如，这段代码：

　　常数a=1；

　　设b；

　　if (a===1) {

　　b= 1111

　　}否则{

　　b= 2222

　　}因为A是1，所以会一直执行到b= 1111这是控制流，也就是程序最终执行的代码，可以用来分析程序的走向，做一些删除死代码之类的优化。

　　随着控制流的执行，B会被赋值为2222，这是数据流的过程，也就是值的变化，可以用来分析某个语句的某个变量的值。

　　程序对不同的数据做不同的处理。如果数据有错误，处理器无法处理，会报错，中断后续的控制流程。比如数据为空，数据格式错误等等。这时应该使用try catch进行错误处理，也叫异常处理。

　　我们进行异常处理有两个目的：

　　对错误的逻辑做点什么。

　　例如，当参数解析出现错误时，在catch中分配一个默认值。这种错误处理后就不需要上报了。在这种情况下，try catch也是逻辑的一部分，相当于if else。

　　对报告的错误进行更现场的描述。

　　JS的错误是JS引擎抛出的。例如，调用空对象方法将报告TypeError，使用未声明的变量将报告ReferenceError。虽然在不同的情况下会报告特定的错误，但它有不同的含义：

　　如果该对象是用户输入的，则用户的输入有错误。如果这个对象是从服务器获取的，就说明服务器返回的数据有错误。在不同的场景下，同一个错误会有更具体的含义，所以我们要做try catch。然后抛出自定义错误，包含场景信息的错误描述。

　　许多库和框架在这方面做得很好。上报的错误都有具体的场景信息甚至解决方案，有的还用错误号管理。您可以通过错误号查询解决方案这是对错误的自定义处理。

　　但是，很多业务代码中报告的错误并不是这样处理的，而是直接报告原生错误。我们会通过异常监控平台收集一些抛出到全局的错误，而这些错误往往是原始的信息。尽管它们带来了错误位置和堆栈，但我们必须查看源代码来定位问题。

　　比如我报了一个对象为空的错误，但是我怎么知道什么对象是空的，原因是什么，怎么解决，有没有编号？

　　如果能在捕捉到各种错误后，在特定场景抛出一些自定义错误，岂不是好很多？这些第三方库都做得不错，但是业务代码中很少有人关注场景中的自定义错误。

　　当然，前端业务代码的用户通过接口使用软件。其实他们只需要针对各种错误做一些UI提示。库的代码是给开发者看的，需要描述场景中的各种错误，甚至对错误进行编号，给出解决方案。

　　但我认为业务代码也应该像第三方库代码一样对待错误。与其报告无意义的原生错误，不如报告一些有特定意义的自定义错误，这样排查和解决问题会容易很多。

　　然而，尽管基于场景的自定义错误可以更好地帮助解决问题，但它必须基于此代码可能报告的错误的确定性。如果自己报告的错误信息与错误的实际原因不同，会增加故障排除的难度。还不如报原错误。

总结

　　程序执行的过程是控制流，受控制语句的影响，执行过程中数据会发生变化。数据的变化称为数据流。控制流和数据流是程序分析中经常分析的两个方面。

　　错误会中断控制流，所以我们必须通过try catch对它们做些什么。

　　错误处理有两个目的：

　　一种是做一些彻底的处理，相当于if else，不需要报错。

　　一种是对原生JS错误做一个场景描述，用更具体的信息创建一个错误对象并抛出。

　　很多图书馆在这方面做得很好，甚至会对错误进行编号，并给出解决方案。但实际上很多业务代码只是对用户的UI进行反馈，并没有将抛出的错误进行场景化包装。这就导致了错误监控平台收集到的错误都是原语错误，需要查看源代码进行调查。如果还能像库代码一样做一些场景错误打包，那么统计和排查问题就容易多了，这是大多数Javascript工程师都没能做到的。

　　有关编程的更多信息，请访问：编程视频！以上是对JS中try catch语句的深入分析，说说它的两个作用！更多详情请关注我们的其他相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。