一种受检异常检测方法、装置、设备及存储介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种受检异常检测方法、装置、设备及存储介质。

背景技术

随着计算机技术的发展，在计算机软件开发过程中有多种编程语言以供使用，常用的语言有：C语言、C++语言、Java语言、Python语言及数据库开发语言等。在Java语言中通过受检异常(CheckedException)处理功能可以在编译阶段强制检查异常，使得发现错误的时期是在编译期间，而不是在运行时期，通过直观的异常提示简化了处理异常的方式。

但是在其他语言，例如Kotlin语言中，没有CheckedException功能，在Kotlin中所有的异常都不强制进行异常的检查，关于异常无法进行静态分析，此时需要依赖开发人员自己分析及梳理需要处理的异常，浪费了时间和精力。

发明内容

本发明实施例提供了受检异常检测方法、装置、设备及存储介质，可以及时反馈未处理的受检异常，有利于提高待检测程序的正确性及安全性。

第一方面，本发明实施例提供了一种受检异常检测方法，该方法包括：

接收受检异常检测指令，其中，所述受检异常检测指令在对基于预设编程语言编写的待检测程序的编译过程中生成；

利用静态语法树分析功能对所述待检测程序进行分析，得到所述待检测程序中未处理的受检异常；

反馈所述未处理的受检异常。

第二方面，本发明实施例提供了一种受检异常检测方法，该方法包括：

在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令；

将所述受检异常检测指令发送至预设受检异常检测组件，以对所述预设受检异常检测组件进行调用，所述预设受检异常检测组件用于实现如本发明实施例第一方面中所述的受检异常检测方法；

接收所述预设受检异常检测组件反馈的所述待检测程序中未处理的受检异常，并采用预设方式展示所述未处理的受检异常。

第三方面，本发明实施例提供了一种受检异常检测装置，该装置包括：

检测指令接收模块，用于接收受检异常检测指令，其中，所述受检异常检测指令在对基于预设编程语言编写的待检测程序的编译过程中生成；

受检异常确定模块，用于利用静态语法树分析功能对所述待检测程序进行分析，得到所述待检测程序中未处理的受检异常；

受检异常反馈模块，用于反馈所述未处理的受检异常。

第四方面，本发明实施例提供了一种受检异常检测装置，该装置包括：

检测指令生成模块，用于在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令；

检测指令发送模块，用于将所述受检异常检测指令发送至预设受检异常检测组件，以对所述预设受检异常检测组件进行调用，所述预设受检异常检测组件用于实现如本发明实施例第一方面中所述的受检异常检测方法；

受检异常展示模块，用于接收所述预设受检异常检测组件反馈的所述待检测程序中未处理的受检异常，并采用预设方式展示所述未处理的受检异常。

第五方面，本发明实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如本发明实施例所述的受检异常检测方法。

第六方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例所述的受检异常检测方法。

本发明实施例中提供的受检异常检测方案，首先接收受检异常检测指令，然后利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常。通过采用上述技术方案，利用静态语法树分析功能得到待检测程序中未处理的受检异常，能够及时反馈未处理的受检异常，有利于提高待检测程序的正确性及安全性。

附图说明

图1A为本发明实施例一提供的一种受检异常检测方法的流程示意图；

图1B为本发明实施例一提供的一种受检异常检测方法的原理示意图；

图2A为本发明实施例二提供的一种受检异常检测方法的流程示意图；

图2B为本发明实施例二提供的一种受检异常检测方法的原理示意图；

图3A为本发明实施例三提供的一种受检异常检测方法的流程示意图；

图3B为本发明实施例三提供的一种受检异常检测方法的原理示意图；

图3C为本发明实施例三提供的方法中展示未处理受检异常的示意图；

图4为本发明实施例四提供的一种受检异常检测装置的结构示意图；

图5为本发明实施例五提供的一种受检异常检测装置的结构示意图；

图6为本发明实施例六提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

相关技术中，Java语言通过CheckedException功能可以在编译阶段强制检查程序中的异常，通过直观的异常提示简化了处理异常的方式，但是在其他语言，例如Kotlin语言中，没有CheckedException功能，所有的异常都不强制进行异常的检查，关于异常无法进行静态分析，此时需要依赖开发人员自己分析及梳理需要处理的异常，浪费了时间和精力，本发明实施例设计了一种新的受检异常检测方法，首先接收受检异常检测指令，然后利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常，利用静态语法树分析功能得到待检测程序中未处理的受检异常，能够及时反馈未处理的受检异常，有利于提高待检测程序的正确性及安全性，为开发人员节省了大量的时间以及精力。

实施例一

图1A为本发明实施例一提供的一种受检异常检测方法的流程示意图，图1B为本发明实施例一提供的一种受检异常检测方法的原理示意图。本实施例提供的受检异常检测方法可以由受检异常检测装置执行，其中该装置可由软件和/或硬件实现，并集成在执行本方法的计算机设备中。

参考图1A，本实施例中可以包括如下步骤：

S101，接收受检异常检测指令。

其中，所述受检异常检测指令在对基于预设编程语言编写的待检测程序的编译过程中生成。示例性的，预设编程语言可以是Kotlin语言，还可以是其他不具备受检异常检测功能的语言。

为了能够及时的对受检异常进行检测，那么首先要接收受检异常检测指令，以便后续利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常。

示例性的，本发明实施例中执行方法所对应的程序代码可以以jar包或其他形式存在，可以被称为预设受检异常检测组件。受检异常检测指令可以由编译器或其他具备编译功能的工具(如命令行)生成，并发送给预设受检异常检测组件，通过受检异常检测指令调用预设受检异常检测组件，以实现预设受检异常检测组件的加载。

S102，利用静态语法树分析功能对所述待检测程序进行分析，得到所述待检测程序中未处理的受检异常。

其中，静态语法树是对程序设计语言写成的源代码的一种树型表示。树中的每一个节点(node)代表在源代码中存在的一个构建体。

在接收受检异常检测指令之后，可以利用静态语法树的分析功能对待检测程序进行分析，通过在编译阶段进行静态代码扫描，可以过滤出需要检查的异常，也就能够得到待检测程序中未处理的受检异常。本实施例通过在编译阶段将异常问题暴露出来，能够增强代码的健壮性和质量，避免运行时的错误崩溃。

S103，反馈所述未处理的受检异常。

在得到待检测程序中未处理的受检异常之后，反馈未处理的受检异常，以便开发人员能够针对所反馈的未处理受检异添加异常处理逻辑，防止程序运行时发生错误甚至崩溃，造成不必要的损失。示例性的，可以将未处理的受检异常反馈至受检异常检测指令的发送方；也可直接以一定的方式显示未处理的受检异常，供开发人员参考，如在预设界面显示未处理的受检异常对应的异常抛出处的相关代码，如在网页html报表中显示。

本实施例提供的技术方案，首先接收受检异常检测指令，然后利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常。通过采用上述技术方案，利用静态语法树分析功能得到待检测程序中未处理的受检异常，能够及时反馈未处理的受检异常，有利于提高待检测程序的正确性及安全性，为开发人员节省了大量的时间以及精力。

实施例二

图2A为本发明实施例二提供的一种受检异常检测方法的流程示意图，图2B为本发明实施例二提供的一种受检异常检测方法的原理示意图；本实施例是在上述各可选实施例的基础上进行优化。具体的，如图2A所示，本实施例中对得到待检测程序中未处理的受检异常的过程进行详细的解释说明。

参考图2A，本实施例中可以包括如下步骤：

S201，接收受检异常检测指令。

S202，利用静态语法树分析功能获取所述待检测程序中的调用栈中包含的调用方法以及所述调用方法之间的继承关系信息。

程序在运行过程中，会产生调用栈。调用栈是一种栈结构，可以存储计算机程序执行时，活跃程序的信息，例如，什么函数正在执行，什么函数正在被另一函数调用等信息。因此，在接收受检异常检测指令后，可以利用静态语法树分析功能对待检测程序进行分析，从而获取到待检测程序在运行过程中的调用栈中所包含的调用方法以及调用方法之间的继承关系信息(即父类和子类的关系)，以便后续通过对调用方法和继承关系信息进行分析，得到待检测程序中未处理的受检异常。

可选的，所述静态语法树分析功能基于Lint实现，所述利用静态语法树分析功能获取所述待检测程序中的调用栈中包含的调用方法以及所述调用方法之间的继承关系信息，可以具体包括：基于Lint创建继承于Detector类并实现统一抽象语法树(UnifiedAbstract Syntax Tree，简称Uast)扫描UastScanner接口的受检异常检测类；通过所述受检异常检测类获取所述待检测程序中的调用栈中包含的调用方法以及所述调用方法之间的继承关系信息。

Lint是一种静态代码分析工具，通过Lint可以实现静态语法树分析功能。需要说明的是静态语法树分析功能还可以通过其他工具实现，例如ASM。

首先通过Lint工具可以创建受检异常检测类，该受检异常检测类继承于Detector类，能够实现UastScanner接口，通过UastScanner接口可以将待检测程序的源代码转化为抽象语法树，建立一个清晰的接口，然后通过受检异常检测类可以获取到待检测程序中的调用栈中包含的调用方法以及调用方法之间的继承关系信息，其中，继承是从已有的类中派生出新的类，新的类能吸收已有类的数据属性和行为，并能扩展新的能力。

进一步的，所述通过所述受检异常检测类获取所述待检测程序中的调用栈中包含的调用方法以及所述调用方法之间的继承关系信息，可以具体包括：将所述受检异常检测类中的isCallGraphRequired()方法返回true，并利用所述受检异常检测类中的analyzeCallGraph方法获取所述待检测程序中的调用栈中包含的调用方法以及所述调用方法之间的继承关系信息。本发明实施例通过analyzeCallGraph方法可以进行调用栈的分析，得到调用方法和继承关系信息，以便后续对调用方法和所述继承关系信息进行分析，得到所述待检测程序中未处理的受检异常。

S203，对所述调用方法和所述继承关系信息进行分析，得到所述待检测程序中未处理的受检异常。

由于受检异常存在于异常类中，而异常类是Throwable类的子类，那么通过对调用方法和继承关系信息进行分析，就能够得到待检测程序中未处理的受检异常。

可选的，所述对所述调用方法和所述继承关系信息进行分析，得到所述待检测程序中未处理的受检异常，可以具体包括：查看所述调用方法的函数声明处是否存在需要捕获的目标受检异常；若存在，则将所述目标受检异常以及所述目标受检异常对应的继承关系信息作为受检异常信息，加入到受检异常信息集合；对所述受检异常信息集合中的受检异常信息进行分析，确定所述待检测程序中未处理的受检异常。

具体的，通过调用栈分析，首先查看调用方法的函数声明处是否存在需要捕获的目标受检异常，如果调用方法的函数声明处存在需要捕获的目标受检异常，则将目标受检异常以及目标受检异常对应的继承关系信息作为受检异常信息，加入到受检异常信息集合，然后对受检异常信息集合中的受检异常信息进行分析，进而可以确定待检测程序中是否存在未处理的受检异常。

本发明实施例通过先收集受检异常信息，然后再分析受检异常信息，而不是边收集边分析，可以保证分析过程的准确性，以免遗漏未处理的受检异常。

进一步的，所述查看所述调用方法的函数声明处是否存在需要捕获的目标受检异常，可以具体包括：查看所述调用方法的函数声明处抛出的所有异常类；根据所述继承关系信息判断所述所有异常类中是否存在预设异常类之外的目标异常类，若存在，则将所述目标异常类确定为需要捕获的目标受检异常。

其中，所述预设异常类包括错误类和错误类的子类、以及运行时异常类和运行时异常类的子类。

具体的，由于异常类中可能涉及到父类和子类，因此可以根据异常类的继承关系，首先查看调用方法的函数声明处抛出的所有异常类中都有什么异常类，然后根据继承关系信息判断在所有异常类中是否存在除了错误类和错误类的子类、以及运行时异常类和运行时异常类的子类之外的目标异常类，如果存在，说明调用方法的函数声明处存在需要捕获的目标受检异常，则将该目标异常类确定为需要捕获的目标受检异常；如果不存在，说明调用方法的函数声明处不存在需要捕获的目标受检异常。

其中，所有异常类中最上层的父类是Throwable类，它是错误Error类和异常Exception类的父类，只有继承于Throwable的类或者其子类才能被抛出；Error：继承于Throwable，是系统致命错误，程序无法处理和恢复的错误，例如OutOfMemoryError、ThreadDeath等。这些错误发生时，Java虚拟机只能终止线程；Exception：继承于Throwable，是程序可以处理或者尝试回复的异常，这种异常是设计中早已考虑到很常见的错误，它分为两类即运行时异常RuntimeException类和CheckedException类；RuntimeException：是编译期不强制检查的异常，例如NullPointException、IndexOutOfBoundsException及IllegalAygumentException等；CheckedException：是继承于Exception并且需要强制检查的异常，例如ClassNotFoundException、NoSuchFieldException、JSONException及IOException等。

示例性的，判断是否是目标受检异常的方法可以为：检查该异常是否是Throwable或者异常Exception的子类；如果是Throwable的子类，则判断该异常是错误Error类还是Exception类，若是Error类则该异常不是目标受检异常；若是Exception类，则判断该异常是否是运行时异常RuntimeException类及RuntimeException类的子类，若是RuntimeException类及RuntimeException类的子类，则该异常不是目标受检异常，否则，该异常是目标受检异常；如果该异常是Exception的子类，则直接判断该异常是否是RuntimeException类及RuntimeException类的子类，如果不是，则确定该异常是目标受检异常。

示例性的，受检异常信息集合map的获取方式可以为：先分析调用方法的函数声明处声明的异常是否是java.lang.RuntimeException和java.lang.Error，如果是，则说明该异常是不受检异常(NotCheckedException)，如果不是，就分析异常的继承关系，如果该异常的父类是RuntimeException或Error则不用检查退出流程，如果该异常的父类是Exception或Throwable则需要检查，然后放入受检异常信息集合map中。如果以上都不是的话，则递归检查父类的父类，一直向上递归直到找到Exception或Throwable终止。这样就收集到了一个受检异常信息集合map，在map中可以通过key存放异常类，通过value存放该异常的继承列表。

本发明实施例通过查看调用方法的函数声明处抛出的所有异常类以及根据继承关系信息能够更准确的确定需要捕获的目标受检异常，避免出现在Kotlin语言中，没有CheckedException功能，无法静态分析异常，导致开发人员在写代码的时候就要主动关注异常，查看代码调用栈里有哪些异常，然后分别处理异常的问题。尤其是对于从Java语言切换到kotlin的开发人员来说，习惯了Java语言的受检查异常功能，也就不会主动去查看调用栈里的异常情况。例如在排查项目代码时，搜索关键字JSONObject会发现项目中Kotlin的代码里几乎所有调用的地方都没有尝试捕获异常(Try-catch)，如果服务器下发的JSON串不符合格式或者本地文件的JSON文件信息损坏了，调用上面的代码将会直接导致线上的崩溃(crash)。

进一步的，所述对所述受检异常信息集合中的受检异常信息进行分析，确定所述待检测程序中未处理的受检异常，可以具体包括：针对所述受检异常信息集合中的每个受检异常信息，采用预设规则根据当前受检异常信息判断对应的当前目标受检异常是否已被处理，若未被处理，则将所述当前目标受检异常确定为未处理受检异常；汇总所有未处理受检异常，得到所述待检测程序中未处理的受检异常。

其中，预设规则为开发人员设计的可以判断对应的当前目标受检异常是否已被处理的规则。

本发明实施例采用预设规则根据当前受检异常信息判断对应的当前目标受检异常是否已被处理，然后汇总所有未处理受检异常，进而可以得到待检测程序中未处理的受检异常，以便后续开发人员可以及时对未处理的受检异常进行检查以及处理，避免造成程序崩溃问题。

可选的，所述采用预设规则根据当前受检异常信息判断对应的当前目标受检异常是否已被处理，可以具体包括：根据当前受检异常信息确定对应的当前目标受检异常；判断所述当前目标受检异常所对应的函数体中是否已申明所述当前目标受检异常；若已申明，则确定所述当前目标受检异常已被处理。

具体的，由于受检异常信息中包括目标受检异常以及目标受检异常对应的继承关系信息，那么可以根据当前受检异常信息确定对应的当前目标受检异常，然后判断当前目标受检异常所对应的函数体中是否已申明当前目标受检异常，例如，可以通过检查调用处所包含的函数体中是否已经申明throws了对应异常或者异常的父类，如果申明throws了Exception则直接退出。然后遍历map，查看throws的异常是否是异常本身或者异常的父类，如果是就从map中删除对应的key和value，这个过程可以称为第一层过滤。如果已申明，则确定当前目标受检异常已被处理，否则，说明当前目标受检异常可能未被处理。

本发明实施例通过对函数体中是否已申明当前目标受检异常进行判断，即第一层过滤，能够确定当前目标受检异常是否被处理，进而可以确定出未处理的受检异常。

进一步的，在所述判断所述当前目标受检异常所对应的函数体中是否已申明所述当前目标受检异常之后，还可以具体包括：若未申明，则判断所述当前目标受检异常所对应的函数体中是否已针对所述当前目标受检异常进行尝试捕获异常处理；若已进行尝试捕获异常处理，则确定所述当前目标受检异常已被处理。

具体的，在当前目标受检异常所对应的函数体中未申明当前目标受检异常的情况下，可以判断当前目标受检异常所对应的函数体中是否已针对当前目标受检异常进行尝试捕获异常(Try-catch)处理，如果已进行尝试捕获异常处理，则说明当前目标受检异常已被处理，此时可以继续遍历map，查看catch块中的异常是否是异常本身或者异常的父类，如果是就从map中删除对应的key和value，这个过程可以称为第二层过滤。

本发明实施例通过Try-catch能够进一步判断函数体中未申明当前目标受检异常的当前目标受检异常是否被处理，通过第二层过滤，所得到的待检测程序中未处理的受检异常将会更为准确。

更进一步的，所述判断所述当前目标受检异常所对应的函数体中是否已针对所述当前目标受检异常进行尝试捕获异常处理，可以具体包括：判断所述当前目标受检异常所对应的函数体中是否包含尝试捕获异常处理对应的捕获代码块；若包含，则判断所述捕获代码块中包含的异常是否为所述当前目标受检异常或所述当前目标受检异常的父类；若是，则确定所述当前目标受检异常所对应的函数体中已针对所述当前目标受检异常进行尝试捕获异常处理。

本发明实施例通过查看代码块里面是否含有Try-catch的字样，可以判断当前目标受检异常是否已进行尝试捕获异常处理。

可选的，在经过上面的两层过滤后，如果map中还有未处理的异常，那么就需要报告出Lint扫描的警告信息，并且将map中还存在的异常列表输出到警告信息中，告诉开发人员还有哪些异常没有得到处理。

本发明实施例通过Lint扫描出需要进行处理的CheckedException，使得Kotlin语言拥有类似于Java语言的在编译阶段的CheckedException静态代码分析功能，并给出未处理受检异常列表，交给开发人员决定如何处理这些受检异常，从而将Kotlin语言中需要处理的受检异常暴露在编译阶段，增强了Kotlin代码的健壮性。

S204，反馈所述未处理的受检异常。

本实施例提供的技术方案，首先接收受检异常检测指令，接着利用静态语法树分析功能获取待检测程序中的调用栈中包含的调用方法以及调用方法之间的继承关系信息，然后对调用方法和所述继承关系信息进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常，通过对调用栈中包含的调用方法以及调用方法之间的继承关系信息进行分析，可以确定待检测程序中未处理的受检异常，然后反馈未处理的受检异常，解决了现有技术中需要依赖开发人员自己分析及梳理需要处理的异常的问题，有利于提高待检测程序的正确性及安全性，为开发人员节省了大量的时间以及精力。

实施例三

图3A为本发明实施例三提供的一种受检异常检测方法的流程示意图，图3B为本发明实施例三提供的一种受检异常检测方法的原理示意图。本实施例可适用于对未处理的受检异常进行展示的情况。本实施例提供的受检异常检测方法可以由受检异常检测装置执行，其中该装置可由软件和/或硬件实现，并集成在执行本方法的计算机设备中。

参考图3A，本实施例中可以包括如下步骤：

S301，在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令。

在编译器例如AndroidStudio或其他具备编译功能的工具中，对基于预设编程语言编写的待检测程序进行编译的过程中，可以生成受检异常检测指令，以便后续将受检异常检测指令发送至预设受检异常检测组件，以对预设受检异常检测组件进行调用。

S302，将所述受检异常检测指令发送至预设受检异常检测组件，以对所述预设受检异常检测组件进行调用。

其中，所述预设受检异常检测组件用于实现如本发明实施例前文所述的受检异常检测方法，预设受检异常检测组件可以以jar包形式存在。

将受检异常检测指令发送至预设受检异常检测组件，以对预设受检异常检测组件进行调用，加载预设受检异常检测组件，预设受检异常检测组件接收到受检异常检测指令后，利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常。

本发明实施例通过预设受检异常检测组件可以得到待检测程序中未处理的受检异常。

S303，接收所述预设受检异常检测组件反馈的所述待检测程序中未处理的受检异常，并采用预设方式展示所述未处理的受检异常。

在接收到预设受检异常检测组件反馈的待检测程序中未处理的受检异常之后，可以采用预设方式展示未处理的受检异常，以便提醒开发人员及时处理展示的未处理受检异常。

可选的，所述采用预设方式展示所述未处理的受检异常，可以具体包括：在预设界面显示所述未处理的受检异常对应的异常抛出处的相关代码，和/或，在编译界面中将所述未处理的受检异常对应的异常抛出处的相关代码进行显示方式变更处理。

具体的，可以在预设界面显示未处理的受检异常对应的异常抛出处的相关代码(即出错的这一行代码，或者还可以多显示一些与出错代码相关的上下文代码)，例如在网页html报表中显示，和/或，在编译界面中将未处理的受检异常对应的异常抛出处的相关代码进行显示方式变更处理，例如将相关代码的颜色变为红色，可以更醒目。

示例性的，图3C为本发明实施例三提供的方法中展示未处理受检异常的示意图，如图3C所示：

Lint扫描出kotlin代码中未处理的CheckedException，图中箭头第一处是根据json字符串新创建JSONObject对象，这个过程中如果json串不是正确的Json格式则会抛出JSONException，而代码处如果不进行Try-catch的话，会造成线上的崩溃隐患。图中箭头第二处是获取jsonObject中的JSONArray，如果值为空或者类型不匹配也会导致崩溃，需要增加异常处理逻辑。通过Lint自动扫描出出未处理的受检异常，然后提示开发人员来解决问题。

本发明实施例采用预设方式展示未处理的受检异常，通过醒目的展示方式可以使开发人员看到未处理的受检异常，然后对未处理的受检异常进行处理，防止程序瘫痪或者崩溃。

进一步的，在检测到所述待检测程序进入代码合并阶段，或者，在检测到预设定时检测任务被触发时，再次生成受检异常检测指令，并将再次生成的受检异常检测指令发送至预设受检异常检测组件。

具体的，如果在编译过程中开发人员看到了展示的未处理受检异常，但是由于太忙或者其他原因，可能没有及时的对未处理受检异常进行处理，那么在检测到待检测程序进入代码合并阶段，或者，在检测到预设定时检测任务被触发时，能够再次生成受检异常检测指令，并将再次生成的受检异常检测指令发送至预设受检异常检测组件，可以通过预设受检异常检测组件再一次进行未处理的受检异常反馈，对开发人员继续进行提醒，直到未处理的受检异常被处理了，则停止再次生成受检异常检测指令。

本实施例提供的技术方案，首先在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令，然后将受检异常检测指令发送至预设受检异常检测组件，以对预设受检异常检测组件进行调用，最后接收预设受检异常检测组件反馈的待检测程序中未处理的受检异常，并采用预设方式展示未处理的受检异常，通过采用上述技术方案，利用预设受检异常检测组件中的静态语法树分析功能得到待检测程序中未处理的受检异常，接收预设受检异常检测组件反馈的未处理的受检异常，并展示未处理的受检异常，使得开发人员在看到未处理的受检异常时能够及时处理，有利于提高待检测程序的正确性及安全性，节省了大量的时间以及精力。

实施例四

图4为本发明实施例四提供的一种受检异常检测装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在计算机设备中。如图4所示，该装置可以包括：

检测指令接收模块401，用于接收受检异常检测指令，其中，所述受检异常检测指令在对基于预设编程语言编写的待检测程序的编译过程中生成；

受检异常确定模块402，用于利用静态语法树分析功能对所述待检测程序进行分析，得到所述待检测程序中未处理的受检异常；

受检异常反馈模块403，用于反馈所述未处理的受检异常。

本实施例提供的技术方案，首先接收受检异常检测指令，然后利用静态语法树分析功能对待检测程序进行分析，得到待检测程序中未处理的受检异常，最后反馈未处理的受检异常。通过采用上述技术方案，利用静态语法树分析功能得到待检测程序中未处理的受检异常，能够及时反馈未处理的受检异常，有利于提高待检测程序的正确性及安全性，为开发人员节省了大量的时间以及精力。

本实施例提供的受检异常检测装置可适用于上述实施例一和实施例二提供的受检异常检测方法，具备相应的功能和有益效果。

实施例五

图5为本发明实施例五提供的一种受检异常检测装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在计算机设备中。如图5所示，该装置可以包括：

检测指令生成模块501，用于在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令；

检测指令发送模块502，用于将所述受检异常检测指令发送至预设受检异常检测组件，以对所述预设受检异常检测组件进行调用，所述预设受检异常检测组件用于实现如本发明上述实施例一和实施例二所述的受检异常检测方法；

受检异常展示模块503，用于接收所述预设受检异常检测组件反馈的所述待检测程序中未处理的受检异常，并采用预设方式展示所述未处理的受检异常。

本实施例提供的技术方案，首先在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令，然后将受检异常检测指令发送至预设受检异常检测组件，以对预设受检异常检测组件进行调用，最后接收预设受检异常检测组件反馈的待检测程序中未处理的受检异常，并采用预设方式展示未处理的受检异常，通过采用上述技术方案，利用预设受检异常检测组件中的静态语法树分析功能得到待检测程序中未处理的受检异常，接收预设受检异常检测组件反馈的未处理的受检异常，并展示未处理的受检异常，使得开发人员在看到未处理的受检异常时能够及时处理，有利于提高待检测程序的正确性及安全性，节省了大量的时间以及精力。

本实施例提供的受检异常检测装置可适用于上述实施例三提供的受检异常检测方法，具备相应的功能和有益效果。

实施例六

图6为本发明实施例提供的一种计算机设备的结构示意图，如图6所示，该计算机设备包括存储器601、处理器602和通信装置603；计算机设备中处理器601的数量可以是一个或多个，图中以一个处理器601为例；计算机设备中的存储器601、处理器602和通信装置603可以通过总线或其他方式连接，图6中以通过总线连接为例。

本实施例提供的一种计算机设备可用于执行上述任意实施例提供的受检异常检测方法，具备相应的功能和有益效果。

实施例七

本发明实施例七还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可实现上述任意实施例中的受检异常检测方法。该方法可以具体包括：

接收受检异常检测指令，其中，所述受检异常检测指令在对基于预设编程语言编写的待检测程序的编译过程中生成；

利用静态语法树分析功能对所述待检测程序进行分析，得到所述待检测程序中未处理的受检异常；

反馈所述未处理的受检异常。

或者，

在对基于预设编程语言编写的待检测程序进行编译的过程中，生成受检异常检测指令；

将所述受检异常检测指令发送至预设受检异常检测组件，以对所述预设受检异常检测组件进行调用，所述预设受检异常检测组件用于实现如本发明上述实施例一和实施例二提供的受检异常检测方法；

接收所述预设受检异常检测组件反馈的所述待检测程序中未处理的受检异常，并采用预设方式展示所述未处理的受检异常。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所述的受检异常检测方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述受检异常检测装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。