WO2009146612A1

WO2009146612A1 - 嵌入式c语言环境下异常处理方法及装置

Info

Publication number: WO2009146612A1
Application number: PCT/CN2009/070492
Authority: WO
Inventors: 余加强; 郑伟
Original assignee: 华为技术有限公司
Priority date: 2008-06-03
Filing date: 2009-02-20
Publication date: 2009-12-10
Also published as: CN101599039B; CN101599039A

Description

嵌入式 c语言环境下异常处理方法及装置本申请要求了 2008年 6月 3日递交的申请号为 200810100060.5，发明名称为"嵌入式 C语言环境下异常处理方法及装置"的中国专利申请的优先权，其全部内容通过引用结合在本申请中。技术领域

本发明涉及 C语言技术，尤其涉及嵌入式 C语言环境下异常处理技术。背景技术

异常是指硬件或软件程序在运行时出现的反常情形。在嵌入式 c语言环境下，传统的异常处理方法是，当发现异常时，重启系统。以程序异常为例，可以通过 CPU的异常识别能力，检查程序运行时是否出现异常，一旦 CPU发现程序运行时出现异常，则调用异常处理程序，将包含寄存器、当前堆栈、调用栈在内的异常信息保存下来，然后按统一的方式完成处理。 g卩，对于发生在任务中的异常，调试版本下挂起该任务，在正式版本中重启嵌入式系统，对于发生在中断中的异常，则均以重启嵌入式系统的方式进行处理。

发明人经过仔细研究现有技术后发现，随着软件复杂度的日益增加，系统重启需要更长的时间，而产品对系统的中断时间要求越来越短，甚至不希望系统运行时发生中断，而在嵌入式 C语言环境下，传统的异常处理方法无法满足这样的需求。发明内容

本发明实施例在于提供一种嵌入式 C语言环境下异常处理方法、装置及嵌入式系统，用以实现当异常发生时，缩短系统的中断时间，或者不发生中断。一种嵌入式 c语言环境下的异常处理方法，包括：监控正在运行的需要保护的程序代码片段，如果所述程序代码片段出现异常，则抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常，其中，所述异常处理程序与所述程序代码片段相互独立。

一种嵌入式 C语言环境下异常处理装置，包括：监控单元，用于监控正在运行的需要保护的程序代码片段；异常抛出单元，用于在所述监控单元发现所述程序代码片段出现异常后，抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；匹配单元，用于根据获得的所述异常，确定对应的异常处理程序，所述异常处理程序用于处理所述异常抛出单元抛出的异常，其中，所述异常处理程序与所述程序代码片段相互独立。

一种嵌入式 c语言环境下退出线程或进程的方法，应用于线程主动退出的场景，包括：获得线程或进程需要退出的信息；检查需要退出的线程或进程所抛出的异常是否仍然占用资源；如果是，则释放所述占用的资源；退出所述线程或进程。

一种嵌入式 C语言环境下退出线程或进程的装置，包括：信息获得单元，用于获得线程或进程需要退出的信息；资源检查单元，用于在所述信息获得单元获得线程或进程需要退出的信息后，检查需要退出的线程或进程所抛出的异常是否仍然占用资源；资源释放单元，用于在所述资源检查单元检查出需要退出的线程或进程所抛出的异常仍然占用资源，释放所述占用的资源；退出单元，用于在所述资源释放单元释放所述占用的资源后，退出所述线程或进程。

一种嵌入式 C语言环境下删除线程或进程的方法，应用于当前线程或进程被其他线程或进程删除的场景，包括：确定需要删除的线程或进程；检查需要删除的线程或进程所抛出的异常是否仍然占用资源；如果是，则释放所述占用的资源；删除所述线程或进程。一种嵌入式 c语言环境下删除线程或进程的装置，包括：确定单元，用于确定需要删除的线程或进程；资源检查单元，用于在所述确定单元确定需要删除的线程或进程后，检查需要删除的线程或进程所抛出的异常是否仍然占用资源；资源释放单元，用于在所述资源检查单元检查出需要删除的线程或进程所抛出的异常仍然占用资源，释放所述占用的资源；线程或进程删除单元，用于在所述资源释放单元释放所述占用的资源后，删除所述线程或进程。

一种嵌入式系统，包括上述异常处理装置。

在本发明实施例的嵌入式 C语言环境下异常处理方法、装置及嵌入式系统中，如果程序代码片段出现异常，则不是简单的重新运行程序代码片段，而是由独立于程序代码片段的异常处理程序来处理异常，这样，程序在运行时，就不会因为异常而中断运行，满足了产品不希望系统运行时发生中断的需求。

在本发明实施例的嵌入式 c语言环境下退出或删除线程或进程的方法中，无论是退出或者删除线程或进程，都可以释放处理线程或进程抛出的异常所占用的资源，这样，当其他线程或进程需要使用这些资源时，不会因为删除或退出的线程或进程所抛出的异常仍然占用资源而导致其他线程或进程无法使用这些资源。另外，还可以由其他线程删除所需要删除的线程，从而可以实现跨线程删除线程时的异常处理。附图说明

图 1为本发明实施例的嵌入式 c语言环境下异常处理方法的流程图；图 2为本发明实施例的嵌入式 C语言环境下异常处理装置的结构示意图；

图 3为本发明实施例的不同的异常处理程序对应不同的异常类型的示意图；图 4为本发明的嵌入式 C语言环境下异常处理方法一具体实施例的流程图；

图 5为本发明实施例的堆空间存储异常相关信息的存储布局示意图；图 6为本发明实施例的 try块的实现流程图；

图 7为本发明实施例的 except块的实现流程图；

图 8为本发明实施例的捕捉某种特定异常的实现流程图；

图 9为本发明实施例的捕捉处理指定异常的实现流程图；

图 10为本发明实施例的捕捉和处理某一异常区间内的异常的实现流程图；

图 11为本发明实施例的 throw块的实现流程图；

图 12为本发明实施例的异常处理的精细管理方法的流程图；

图 13为本发明实施例的退出线程或进程的方法的流程图；

图 14为本发明实施例的退出线程或进程的装置的结构示意图；图 15为本发明实施例的删除线程或进程的方法的流程图；

图 16为本发明实施例的删除线程或进程的装置的结构示意图。具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一歩详细说明。

在本发明实施例中,对于 C语言环境下嵌入式系统中的异常可以根据不同场景编写具有针对性的异常处理程序，进行局部异常处理并尝试恢复,而不必对所有异常都作重启系统处理，在异常处理完毕后继续执行，从而提高正常流程下的代码运行效率，也简化了编程。在 C语言环境下嵌入式系统中异常处理框架（方便理解，可称为异常处理装置）的实现不依赖于编译器，并且提供给用户对异常处理框架进行精细管理的方法。

本发明实施例中，提供了多种嵌入式 C语言环境下的异常处理方法，其中的一种方法如图 1所示，包括：

歩骤 S101 : 监控正在运行的需要保护的程序代码片段；

歩骤 S102: 如果所述程序代码片段出现异常，则抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；

需要说明的是：本发明实施例的方案不仅适用于软件异常，还适用于硬件异常；当发生硬件异常后，可以尝试恢复异常，避免重启系统；

歩骤 S103 : 根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常，其中，所述异常处理程序与所述程序代码片段相互独立。为了提供对异常抛出时异常处理级别的精细管理，在本发明实施例中，所述监控正在运行的需要保护的程序代码片段的歩骤具体为：根据设置的处理异常的粒度，监控正在运行的需要保护的程序代码片段；

当一程序执行触发异常时，在一种实现下，当正在运行的需要保护的程序代码片段大于或等于设置的处理异常的粒度时，则监控所述正在运行的需要保护的程序代码片段；

当正在运行的需要保护的程序代码片段小于设置的处理异常的粒度时，则不监控所述正在运行的需要保护的程序代码片段，也就是说，就不需要执行后续的歩骤；这里的，所述设置的处理异常的粒度包括函数级别、模块级另 |J、部件级别中的至少一种，其中，所述模块由多个函数组成，所述部件由多个模块组成。例如，用户在调试阶段设置处理异常的粒度为函数级别；当代码稳定后，用户设置处理异常的粒度为模块级别，则代码在抛出异常时只识别模块级的异常。

在本发明实施例中，所述方法进一歩包括：申请用于记录与异常相关的信息的存储空间；贝 I」，在所述程序代码片段出现异常之后，抛出所述异常之前，记录与异常相关的信息。应当理解的是：将与异常相关的信息记录在申请的存储空间中。

在本发明实施例中，所述抛出所述异常的歩骤，在一种实现下，具体为：将所述与异常相关的信息打包后传递出去，这里，所述与异常相关的信息至少包括异常类型标识，应当说明的是：异常类型标识是用于表示当前程序代码片段出现的异常的类型的信息，形式上可以采用数字，或者字符，或者数字和字符的组合，例如：采用不同的字符串表示不同异常类型。

应当理解的是：本发明实施例适用不同类型的异常，在一种实现下，预先可以给不同的具体异常类型分配不同的标识，例如：将异常统一分成、 b、 c、 d、 e、 f (小类），并且同时用另一个标识区分哪些是软件异常，哪些是硬件异常（大类），例如： 1表示软件异常； 0表示硬件异常；需要说明的是：这仅是一个例子，不用于限制本发明实施例方案。

在本发明实施例中，根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常的歩骤，在一种实现下，可以包括：获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识；

确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常。因此，本发明实施例针对不同类型的异常进行不同处理，避免现有技术在遇到异常时，重启系统，导致系统中断时间长的问题。

确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常的歩骤包括：

当所述异常类型标识对应的异常类型与能处理的一种特殊的异常类型匹配时，由与该异常类型匹配的异常处理程序处理该异常；

或，当所述异常类型标识对应的异常类型与能处理的至少一种异常类型中的一种异常类型匹配时，由与该异常类型匹配的异常处理程序处理该异常，其中，能处理的至少一种异常类型可以是数组指定的类型，或者是异常区间内的类型；

或，当存在能处理任何类型异常的异常处理程序时，确定由该匹配任意类型异常的异常处理程序处理所述异常。

需要理解的是：在一种实现下，可以由宏确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，这个宏的形式为 EXCEPT, 该宏可以带有异常类型参数，也可以不带有异常类型参数；

在该宏带有异常类型参数的情况下，具体匹配过程可以包括：获得线程异常信息（即与异常相关的信息）；判断线程异常信息中的异常类型标识是否与异常类型参数中的一种匹配；如果匹配，则执行相应的异常处理程序；如果不匹配，则重新传递（抛出）异常信息。

在该宏不带有异常类型参数的情况下，任何类型的异常都将被相应异常处理程序处理，换句话说， EXCEPT宏一旦获得异常，就交由与所述程序代码片段位置最近的一个异常处理程序去处理异常，也就起到了捕捉所有类型异常的作用。该宏不带有异常类型参数时，包括异常类型标识的异常信息还是传递到 except块宏作处理，用户编写的异常处理程序可以不加区分的进行统一处理。

本发明实施例的方法进一歩包括：如果当前不存在与该异常类型匹配的异常处理程序时，将获得的与异常相关的信息重新传递出去，或者，当都匹配不上时，启动默认处理程序，所述默认处理程序为重启系统。

为了进一歩的提供对异常处理方式的精细管理，在本发明实施例中，根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常的歩骤，在另一种实现下，可以包括：

获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识、指定处理方式标识；需要说明的是：可以通过不同的指定处理方式标识表示不同的指定处理方式，例如： 1表示容错的处理方式； 0表示查错的处理方式。

确定与所述异常类型标识对应的异常类型所匹配，且与所述的指定处理方式标识对应的处理方式所匹配的异常处理程序，由所述异常处理程序处理所述异常。其中，处理方式可以为容错或查错。

当所述处理方式是容错处理方式，由容错方式的异常处理程序处理所述异常；当所述处理方式是查错处理方式，由查错方式的异常处理程序处理所述异常，其中，所述异常处理程序与所述程序代码片段相互独立。

如果当前不存在与该异常类型匹配，且与指定的处理方式匹配的异常处理程序时，将获得的与异常相关的信息重新传递出去，或者，当都匹配不上时，启动默认处理程序，所述默认处理程序为重启系统。

因此，本发明实施例不仅可以实现针对不同类型的异常进行不同的处理，而且还能根据用户设置的方式对异常以不同的处理方式进行处理，例如，在开发阶段，对异常的处理主要方法是捕获异常处理错误并输出错误，而在开发完成产品发布时，异常处理的主要方法是容错恢复。本发明实施例中的异常处理程序还能够匹配和处理多种类型的异常。

如果有多个与所述异常类型相匹配的异常处理程序，则确定与所述异常类型标识对应的异常类型所匹配的异常处理程序的歩骤为：确定与所述异常类型标识对应的异常类型所匹配的，且与所述程序代码片段位置最近的一个异常处理程序。

如果所述程序代码片段被调用时出现异常，则由所述异常处理程序处理所述异常之后，还包括：逐级返回所述程序代码片段正常运行后的结果，或者运行与所述异常处理程序相邻且在其之后的程序代码片段；从而进一歩提高正常流程下的代码运行效率。

在一种实现下，由匹配和捕捉异常功能的宏来匹配和捕捉异常；由具有监控功能的宏来监控正在运行的需要保护的程序代码片段；由具有抛出异常功能的宏来抛出所述异常。

具体的，程序代码片段可以是指函数，也可以是指由多个函数组成的模块，还可以是指由多个模块组成的部件，当然，程序代码片段还可以是其他级别的程序段，这里不再一一列举。在嵌入式 C语言环境下，可以由具有监控功能的宏来监控程序代码片段，例如可以由封装 C语言的 setjmp ( )函数的宏。

当程序代码片段在运行过程中出现异常时，需要抛出异常，而在抛出异常之前，可以记录与异常相关的信息，这样，抛出异常时，可以抛出与异常相关的信息。与异常相关的信息既可以包括软件异常信息，也可以包括硬件异常信息。在嵌入式 C语言环境下，可以由具有抛出异常功能的宏来抛出异常，例如可以由封装 C语言的 longjmp ( ) 函数的宏。

针对需要保护的程序代码片段，可以建立至少一个异常处理程序。每个异常处理程序可以匹配和处理一种类型的异常，也可以匹配和处理多种类型的异常。不同的异常处理程序可以处理同一种类型的异常，当异常被抛出时，可以从中选择一个异常处理程序来处理这种类型的异常，例如，可以选择一个与所述程序代码片段最近的一个异常处理程序处理所述异常。具体的，假设某个程序代码片段之后分别有程序 A、程序 B和程序 C等能够处理同一个异常的异常处理程序，当程序代码片段抛出异常时，如果没有特殊设置，则一般都由程序 A (在程序代码片段之后，在所有的能够处理所述异常的异常处理程序中位置相对于该程序代码片段最靠前）来处理所述异常。

需要说明的是，异常处理程序与程序代码片段是相互独立的，这样至少有两个优点：第一个优点是，程序代码片段在运行过程中如果没有出现异常，则异常处理程序不会被执行，从而不影响程序代码片段的正常运行，客观上也提高了程序代码片段的运行效率；第二个优点是，可以给用户提供是否由异常处理程序来处理异常或者由哪种异常处理程序来处理异常的选择。

在实际应用中，程序代码片段可能是在被调用过程中出现异常，由与所述异常的类型相匹配的异常处理程序处理所述异常之后，可以逐级返回的是程序代码片段正常运行后的结果。例如，函数 A调用函数 B，函数 B调用函数 C,如果函数 C在运行时发生异常，并且存在与异常的类型相匹配的异常处理程序，则可以由异常处理程序处理异常，处理异常后，函数 C可以正常运行，其正常运行的结果可以返回给函数 B，函数 B再将函数 B的运行结果返回给函数 A。由此可见，即使函数 B调用函数 C时，函数 C运行出现异常，但对于函数 A和函数 B来说，这个或这些异常都是不被发现的，函数 A和函数 B得到的分别是函数 B正常运行的结果和函数 C正常运行的结果。另外，由与所述异常的类型相匹配的异常处理程序处理所述异常之后，也可以运行所述异常处理程序之后的程序代码片段。还是以上面的例子为例，即使由异常处理程序处理异常，但不再返回执行函数 C，而是执行后续的程序代码片段，后续的程序代码片段可以是指与异常处理程序相邻且在其位置之后的程序代码片段，也可以是指异常处理程序之后的任意一个程序代码片段。

在嵌入式 C语言环境下，可以由由用 C语言实现的具有匹配和捕捉异常功能的宏来匹配和捕捉异常，例如可以由封装 C语言的 setjmp ( )函数被调用后返回非 0值的 else分支的宏。

其中的一种嵌入式 C语言环境下异常处理装置（也可以称为异常处理框架）如图 2所示，包括：

监控单元 201，用于监控正在运行的需要保护的程序代码片段；异常抛出单元 202，用于在监控单元 201发现所述程序代码片段出现异常后，抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；匹配单元 203，用于根据获得的所述异常，确定对应的异常处理程序，所述异常处理程序用于处理所述异常抛出单元抛出的异常，其中，所述异常处理程序与所述程序代码片段相互独立。

在嵌入式 C语言环境下，将具有监控功能的宏模块化即监控单元，例如可以是封装 C语言的 setjmp ( ) 函数的宏。

另外，上述装置还可以包括：

信息记录单元 204，用于记录与监控单元 201发现的所述程序代码片段出现的异常相关的信息，并输出给所述异常抛出单元 202。这样，异常抛出单元 202在抛出异常时，可以抛出与异常相关的信息。与异常相关的信息既可以包括软件异常信息，也可以包括硬件异常信息。在 C语言环境下，将具有抛出异常功能的宏模块化即异常抛出单元 202，例如可以是封装 C语言的 longjmp ( ) 函数的宏。

异常抛出单元 202为第一异常抛出单元，用于在监控单元 201发现所述程序代码片段出现异常后，将所述与异常相关的信息打包后传递出去，所述与异常相关的信息至少包括异常类型标识，所述异常类型标识用于表示当前程序代码片段出现的异常的类型。

匹配单元 203为第一匹配单元，用于获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识，并确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常。

匹配单元 203为第二匹配单元，用于获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识、指定处理方式标识，并确定与所述异常类型标识对应的异常类型所匹配，且与所述的指定处理方式标识对应的处理方式所匹配的异常处理程序，由所述异常处理程序处理所述异常。例如，可以设置函数级别的异常处理程序，也可以设置模块级别的异常处理程序，还可以设置部件级别的异常处理程序，假设对应这三个级别的异常处理程序都能够处理同一个类型的异常，但处理方式各不相同。用户可以选择处理异常的级别，假设用户选择了模块级别，其对应的异常处理程序的处理方式是容错处理，当需要保护的程序代码片段在运行过程中出现异常，则处理异常的就是模块级别对应的异常处理程序， gp，对异常采取容错方式处理。

处理方式可以包括容错和查错等多种方式，当程序代码片段出现异常时，可以根据设置的处理方式处理异常。例如，如果设置的处理方式是容错处理方式，则可以使用容错方式的异常处理程序处理异常。再例如，如果设置处理方式是查错处理方式，则可以使用查错方式的异常处理程序处理异常，其中，异常处理程序与程序代码片段相互独立。

如果有多个与所述异常的类型相匹配的异常处理程序，匹配单元 203 为第三匹配单元，用于根据获得的所述异常，确定与所述异常的类型所匹配的，且与所述程序代码片段位置最近的一个异常处理程序，由所述异常处理程序处理所述异常。

在一程序执行触发异常时，监控单元 201为第一监控单元，用于根据设置的处理异常的粒度监控所述正在运行的需要保护的程序代码片段。例如：当设置的处理异常的粒度为模块级别时，而所述正在运行的需要保护的程序代码片段是函数级别，则就不需要监控所述正在运行的需要保护的程序代码片段；当设置的处理异常的粒度为函数级别时，而所述正在运行的需要保护的程序代码片段是模块级别，则监控所述正在运行的需要保护的程序代码片段；针对需要保护的程序代码片段，可以建立至少一个异常处理程序。每个异常处理程序可以匹配和处理一种类型的异常，也可以匹配和处理多种类型的异常。

不同的异常处理程序可以处理同一种类型的异常，当异常抛出单元 202 抛出异常时，可以由匹配单元 203从中选择一个异常处理程序来处理这种类型的异常，例如，可以选择一个与所述程序代码片段最近的一个异常处理程序处理所述异常。

在实际应用中，程序代码片段可能是在被调用过程中出现异常，在匹配单元 203确定与所述异常的类型相匹配的异常处理程序，由该异常处理程序处理所述异常之后，程序代码片段可以逐级返回正常运行后的结果。在嵌入式 C语言环境下，将由 C语言实现的具有匹配和捕捉异常功能的宏模块化即匹配单元 203，例如可以是封装 C语言的 setjmp ( ) 函数被调用后返回非 0值的 else分支的宏。

需要说明的是，由于不同的异常处理程序可以适用于不同的异常，为方便识别异常类型，可以给不同的异常类型分配不同的标识，例如：将异常统一分成 a、 b、 c、 d、 e、 f (小类），并且同时用另一个标识区分哪些是软件异常，哪些是硬件异常（大类），例如： 1表示软件异常； 0表示硬件异常。具体的，如图 3所示，首先获得传递过来的与异常相关信息（简称异常信息），该异常信息中包含异常类型标识，经过宏的匹配，确定与该异常类型标识对应的异常类型匹配的异常处理程序，由相应的异常处理程序处理相应的异常类型的异常。

除上述方法实施例和异常处理框架实施例外，本发明还提供了嵌入式系统，所述系统包括上述异常处理装置（即异常处理框架）。具体请参见上述对异常处理框架的描述，这里不再赘述。

除上述方法实施例外，本发明还提供了另外一个方法实施例。具体的，如图 4所示，包括：

歩骤 S401 : 执行程序代码；

歩骤 S402: 判断是否触发异常，如果是，则转歩骤 S403 , 否则，转歩骤 S401 ;

歩骤 S403 : 根据处理异常的粒度，确定与粒度对应的 try块（为描述方便，这里用 try块表示具有监控功能的宏）；

歩骤 S404: 判断 try块是否有 except块（为描述方便，这里用 except 块表示具有捕捉和匹配异常功能的宏），如果是，转歩骤 S406, 否则，转歩骤 S405;

歩骤 S405: 确定更高一级粒度对应的 try块，转歩骤 S404;

歩骤 S406: 判断 except块是否能够处理异常，如果是，转歩骤 S407 , 否则，转歩骤 S405 ;

歩骤 S407: 执行 except块的代码，转歩骤 S401。

本发明实施例首先在嵌入式 C语言环境下建立异常记录信息，建立异常相关信息的存储和传递模型，最终实现异常关联的机制和用户接口。 1.关于异常记录信息

表 1为异常记录信息的一种表现形式。

表 1

在嵌入式 C语言环境下，为了实现异常处理，需要定义异常记录结构，将异常信息保存在该结构中，传递给 except块， except块可以根据异常记录信息来决定处理的方式。异常记录信息如下列代码中的注释所示：

typedef struct _VOS_SEH_REC //异常记录信息

VOS— UINT32 ulSehType; //定义的硬件或软件异常类型

VOS— UINT32 ulSehErrOrlntCode; //软件异常情况下为错误码信息，硬件异常情况下标识是否在中断中异常

VOS— UINT32 ulSehFlag; //异常是否可继续的标识

struct _VOS_SEH_REC *pSehNextRec; //记录异常处理过程中嵌套的异常

VOS—EXC— REG— INFO *pExcRegs; //ulSehType为硬件异常时其指向 CPU寄存器信息记录,软件异常时为空

VOS— UINT32 ulSehAddr; //发生异常的指令地址

VOS— UINT32 ulSehParaNums; //异常附加参数数目

VOS— UINT32 a_SehInfo[EXC_MAX_PARA_NUM]；〃异常附加参数信息

VOS_CHAR scSehMsg[32]; //异常描述字符串 } VOS_SEH_REC;

2：关于异常相关信息的存储和传递模型

在嵌入式 C语言环境下，为支持异常嵌套处理和对多线程异常的处理，需要存储异常相关信息，并根据其生命周期的特点选择适当的存储和传递模型。异常相关信息包括：（1 ) 每个 try块保存其运行上下文环境的 env信息 (info); (2)发生异常后的异常记录信息（即前面定义的 VOS— SEH— REC); (3 ) 各线程的异常状态控制表。

从具有抛出异常功能的宏到具有匹配和捕捉异常功能的宏的信息采用线程范围的栈来存储和传递，其中， env信息所需存储空间需要满足 try块最大嵌套层次的深度，而异常记录信息存储空间则需要满足一次嵌套的最大深度，因此，可以考虑以线程为单位，在线程创建后，分配线程堆空间来存储异常相关信息，存储布局示意可以参照图 5。

env信息是各线程正常运行期间高度动态的信息，每个线程都保留一份。 exc信息（mfo) 则只在线程运行异常情况下才出现，各线程间可以共享使用。

env信息把所有可回溯的环境记录串联起来形成异常范围表，在 throw 块（为描述方便，这里用 throw块表示具有抛出异常功能的宏）操作时通过访问该表来获得相匹配的 except块，该表存储单元需记录的信息如表 2所示：

表 2

具体的数据结构如下：

typedef struct—SEH— SCOPE— UNIT〃异常范围表

VOS— BOOL bllntFlag; //是否在中断背景下设置标志 #ifdef SEH— DEBUG //异常调试

VOS— CHAR *pSehSetFile; //设置异常的文件

VOS_UINT32 ulSehSetLine;//设置异常的行号

#endif

struct—SEH— SCOPE— UNIT *seh— next; //记录链表

} SEH— SCOPE— UNIT;

exc信息把异常记录信息记录下来，在 throw块（相当于上述装置中的异常抛出单元)操作时，将该结构做为信息参数传递给相匹配的 except块 (相当于上述装置中的匹配单元）来处理，如果其中发生异常嵌套，则将信息进行串联。需记录的信息如表 3所示：信息有效标志异常记录信息

表 3 具体数据结构如下：

typedef struct—SEH— EXC— INFO

VOS— UINT32 ulMagic; //信息有效标志

VOS— SEH— REC seh rec; //异常记录

} SEH— EXC— INFO;

各线程间共享的 SHE EXC INFO缓冲区分配控制信息表如表 4所

表 4 具体数据结构如下：

typedef struct—SEH— INFO— BUF— CTRL〃缓冲区分配控制信息表

VOS— UINT32 ulMaxExcInfoNum; //异常最大信息块数

VOS UINT32 ulUsedExcInfoNum; //已分配信息块数 SEH— EXC— INFO *pExcInfoBufFreeLink; //空闲异常信息块链表

} SEH— INFO— BUF— CTRL;

在线程创建成功后，分配的异常状态控制表（exc Ctrl)信息如表 5所

具体数据结构如下：

typedef struct— SEH— TH— CTRL

/*控制信息 */

VOS_UINT32 ulMaxScopeLayer; //线程 try块最大嵌套层数

VOS— UINT32 ulMaxExcNestNum; //线程异常最大嵌套层数

SEH SCOPE U IT *pScopeUnitFreeLink; //空闲范围块链表

/*状态信息 */

VOS— UINT32 ulExceptNestCnt; //线程异常嵌套记数

VOS— UINT32 ulSehStatusFlag; //线程异常当前状态

SEH_EXC_INFO *pSehExdnfo; //异常现场信息地址

SEH SCOPE UINT *_PScopeTableHead; //异常范围链表头

} SEH TH CTRL;

其中， ulSehStatusFlag标志有六种状态，分别是： SEH— STAT— NON (无异常情况下的初始值必须为 0)， SEH STAT U HANDLE (未处理异常）， SEH STAT HANDLED (已处理）， SEH STAT CONTINUE SEARCH (继续回溯异常处理块）， SEH— STAT— CONTINUE— REDO (从异常处重新执行）和 SEH— STAT— RESTART ⁽重启进程或单板）。

对线程异常范围表以单向链表方式组织，按栈序操作，本发明实施例提供如下功能的接口函数： VOS— UINT32 SEH ScopeTablePush (SEH— SCOPE— UINT

*pScopeTableHead, SEH SCOPE UINT *pSehScopeUnit); //异常范围表压栈

SEH— SCOPE— UINT * SEH_ScopeTablePop(SEH_SCOPE_UINT

*pScopeTableHead); //异常范围

//出栈

VOS— BOOL SEH— ScopeTableIsEmpty(SEH— SCOPE— UINT

*pScopeTableHead); //判断异常范围表

//是否为空

对线程异常信息缓冲表的申请释放可提供如下接口功能函数：

SEH_EXC_INFO * SHE_ExcInfoBufAlloc(); //申请线程异常信息缓冲表

VOS UINT32 SEH_ExcInfoBufFree(SEH_EXC_INFO *pSehExcInfo); II 释放线程异常信息缓冲表

3.关于异常处理流程的实现和用户接口设计

标准 C库中提供的 se jmpG、 longjmpG函数可以提供非本地局部跳转的机制。在嵌入式 C语言环境下，不依赖编译器实现异常关联机制，可以采用 setjmp的封装来实现 try块，并在识别异常后调用 longjmp来提供 throw 块， except块则是 setjmp调用后返回非 0值的 else分支。

一、线程异常状态控制表的构造

为实现上述接口，首先需要构造线程异常状态控制表。各线程共享异常信息控制块在系统初始化阶段从系统堆空间申请，保存在指向结构

SEH— INFO— BUF— CTRL的指针 g_pSehInfoBufCtrl中。

在 VxWorks下，任务创建成功后，申请系统堆空间保存 SEH— TH— CTRL，使用 taskVarAdd将指向 SEH— TH— CTRL的指针 _g_pSehThCtrl内容保存在任务变量中，在 try块中可通过局部变量访问 _g_pSehThCtrl，其值由 VxWorks 切换，同时将该堆空间记录在系统任务资源总表中。

在 Linux下，使用 pthread— key— create创建 key句柄，并保存在 key句柄指针 _g_pThKey中，线程创建成功后，申请系统堆空间保存 SEH— TH— CTRL, 调用 pthread— setspecific完成指向 SEH— TH— CTRL的指针 g_pSehThCtrl内容保存，在 try块中通过局部变量保存 pthread— getspecific的返回值（该线程的 _g_pSehThCtrl内容）来操作本线程的异常状态控制表，同时将该堆空间记录在系统线程资源总表中。

当本任务或线程自动退出时，对 g_pSehThCtrl指向的系统堆空间进行释放；当删除其他任务或线程时，对记录在系统资源总表中的其他任务或线程资源进行释放。

二、 try块的设计

try块的实现流程如图 6所示，包括：

歩骤 S601 : 开始执行 try块宏；

歩骤 S602:判断所述 try块对应的粒度是否小于设置的处理异常的粒度，如果是，转歩骤 S608, 否则，转歩骤 S603;

歩骤 S603: 获得当前线程异常状态控制表的地址，转歩骤 S604;

歩骤 S604: 从线程异常状态控制表的空闲范围块链表中申请一个 Unit 块，转歩骤 S605;

歩骤 S605: 初始化 Unit块的 bilntFlag, 将 Unit块压入线程异常范围链表，初始化异常状态控制表的相关项，转歩骤 S606;

歩骤 S606: 调用 setjmpO函数，转歩骤 S607;

歩骤 S607: 判断是否返回 0，如果是，则转歩骤 S608, 否则，转歩骤 S609;

歩骤 S608: 正常处理，转歩骤 S610;

歩骤 S609: 异常处理，转歩骤 S610;

歩骤 S610: 结束执行 try块宏，转歩骤 S611 ;

歩骤 S611 : 判断是否需要回溯，如果是，则转歩骤 S612, 否则，转歩骤 S613; 歩骤 S612: 重新抛出异常；

歩骤 S613: 判断是否需要复位，如果是，则转歩骤 S614, 否则，转歩骤 S615;

歩骤 S614: 重新启动进程或单板处理；

歩骤 S615: 判断是否恢复执行，如果是，转歩骤 S616, 否则，转歩骤

S617;

歩骤 S616: 根据 CPU特点执行异常恢复操作；

歩骤 S617: try块结束处理。

需要说明的是，歩骤 S608和 S609 (即图中虚线部分）为用户处理代码， SP ,用户需要进行的流程，例如需要保护的程序代码片段等正常的程序代码。

具体的， try块从线程异常状态控制表的空闲范围块链表中可以动态申请一个记录单元，如果超过线程 try块最大嵌套层数 ulMaxScopeLayer, 则触发系统默认异常处理。正常情况下，经过少量初始化操作后，将其压入 (push)到线程异常范围链表中，然后在 if语句中调用 setjmp, 对应用程序的正常处理流程代码形成监控，当被监控的代码片段中有硬件或软件异常抛出时，该程序能够恢复到由此 setjmp保存的执行点。为区分 setjmp的返回值是第一次调用（0值），还是 longjmp调用的返回（非 0值），用线程异常状态控制表中的 ulSehStatusFlag记录，当返回非 0时，表示当前异常处理状态，其含义为，匹配该 try块的 except块是否被找到，或者需要进一歩回溯，或者从异常处重新执行，或者需要复位进程或复位单板。此外， try块的实现还需要考虑对异常处理级别的精细管理进行支持。

try块的流程可以通过如下方式实现：

#define SEH— TRY— BEG(SEH— level) \ VOS_INT32 ulSehStatusFlag = 0;\

if(SEH_Level>=SEH_HANDLE_LEVEL)\ 异常框架的精细控制

SEH— SCOPE— UINT *_try_pSehScopeUnit; \

SEH— TH— CTRL *_try__pSehThCtrl; \

_try_pSehThCtrl =当前线程状态控制表地址 \

_try_pSehScopeUnit =从线程空闲范围块链表申请一个 Unit块 \ 根据当前是否在中断中初始化 Unit块 bllntFlag标志 \

调用 SEH— ScopeTablePush将 Unit压入线程异常范围表 \

初始化异常状态控制表状态信息为无异常状态 SEH— STAT— NON \ _try__pSehThCtrl->pSehExcInfo = VOS NULL PTR;

ulSehStatusFlag=一 try _ SehThCtrl->ulSehStatusFlag=setjmp( _ try _ Se h-ScopeUnit->seh_env); if (0 = = ulSehStatusFlag) \

{ —这个正向大括号是对 try块中正常流程代码作用域的引导 try块的实现需要做到不依赖于编译器，无法通过编译器的文法识别来找到 try块的结束点并自动添加结束代码，因此，需要设计一个由应用程序调用的 SEH— TRY— END, 来完成 try块的结束处理，完成对异常状态的清除处理。

#define SEH— TRY— END \

if(SEH— STAT— CONTINUE— SEARCH/*需要进一歩回溯 */ \

= = _try__pSehThCtrl->ulSehStatusFlag) \

SEH RETHROW0; \

} \

else \ SEH_ExcInfoBufFree( _ try _ SehThCtrl->pSehExcInfo); if (SEH— STAT— RESTART/*需要复位进程或单板 */ = =

_try__pSehThCtrl->ulSehStatusFlag) \ 重启进程或单板处理 \

} \

else if (SEH— STAT— CONTINUE— REDO/*需要从异常指令处恢复执行 */ = = _try_pSehThCtrl->ulSehStatusFlag) \ 根据 CPU体系特点执行异常恢复操作 \

} \

}\—这个反向大括号是对 except块中异常处理方式精细管理的作用域的关闭

} \—这个反向大括号是对 except块作用域的关闭

/*没有执行到任何 except块，表明无异常发生 */ \

if (0 = = _try__pSehThCtrl->ulSehStatusFlag) \ 调用 SEH— ScopeTablePop将 Unit弹出线程异常范围表 \

将 Umt块释放回线程异常状态控制表中的线程空闲范围块链表 \

} \

}——这个反向大括号是对整个 try块异常框架作用域的关闭

三、 except块的设计

在 try块之后，需要提供 except块的机制，它实际上就是 SEH— TRY— BEG 封装的 if语句配对的 else分支，可以对 throw块抛出的异常类型进行处理，同时支持异常处理方式的精细处理。具体实现流程如图 7所示，包括：歩骤 S701：开始执行 except块宏；

歩骤 S702: 关闭正常处理分支的作用域或前一个异常处理方式的作用域；

歩骤 S703: 判断是否是当前异常处理方式，如果是，转歩骤 S704, 否贝 |J，转歩骤 S708;

歩骤 S704: 将 Unit块弹出线程异常范围表；

歩骤 S705: 将 Umt块释放到线程异常状态控制表的空闲范围块链表；歩骤 S706: 设置异常已处理的状态；

歩骤 S707: 执行异常处理程序代码，这里的，异常处理程序代码即异常处理代码；

歩骤 S708: 转下一个异常处理方式的 except块或者结束异常处理。封装代码如下：

#define SEH EXCEPT(method) \

} \—这个反向大括号是对 try块中正常流程代码作用域或前一异常处理方式作用域的关闭

else \ if(method = = EXCEPTION HANDLE METHOD) { \——异常处理方式的精细控制

调用 SEH— ScopeTablePop将 Unit弹出线程异常范围表 \

将 Umt块释放回线程异常状态控制表中的线程空闲范围块链表 \ _try_pSehThCtrl->ulSehStatusFlag = SEH— STAT— HANDLED; \ SEH— EXCEPT可以实现对任意类型异常的捕捉，为支持对异常类型的过滤，即捕获特定类型的异常，本发明实施例进一歩提供三种格式的封装。

( 1 ) 捕捉某种特定异常实现流程如图 8所示，包括：

歩骤 S801：开始执行 except块宏；

歩骤 S802: 关闭正常处理分支的作用域或前一个异常处理方式的作用域；

歩骤 S803: 判断是否是当前异常处理方式，如果是，转歩骤 S804, 否则，转歩骤 S810;

歩骤 S804: 将 Unit块弹出线程异常范围表；

歩骤 S805: 判断是否匹配异常类型，如果是，转歩骤 S807, 否则，转歩骤 S806;

歩骤 S806: 重新抛出异常；

歩骤 S807: 将 Umt块释放到线程异常状态控制表的空闲范围块链表；歩骤 S808: 设置异常已处理的状态；

歩骤 S809: 执行异常处理程序代码；

歩骤 S810: 转下一个异常处理方式的 except块或者结束异常处理。

实现代码如下：

#define SEH— EXCEPT— ONE(seh— type， method) \

} \

else \ if(method = = EXCEPTION— HANDLE— METHOD) { \

调用 SEH— ScopeTablePop将 Unit弹出线程异常范围表 \

将 Umt块释放回线程异常状态控制表中的线程空闲范围块链表 \ if (seh type = = _ try _ SehThCtrl->pSehExcInfo->seh_rec.ulSehType) \

_try_pSehThCtrl->ulSehStatusFlag = SEH— STAT— HANDLED; \

} \

else \ SEH RETHROW0; /*重抛异常 *八

} \

(2) 捕捉处理指定异常

实现流程如图 9所示，包括：

歩骤 S901：开始执行 except块宏；

歩骤 S902: 关闭正常处理分支的作用域或前一个异常处理方式的作用域；

歩骤 S903: 判断是否是当前异常处理方式，如果是，转歩骤 S904, 否贝 ij，转歩骤 S910;

歩骤 S904: 将 Unit块弹出线程异常范围表；

歩骤 S905: 判断是否匹配数组指定的异常类型，如果是，转歩骤 S907, 否则，转歩骤 S906;

歩骤 S906: 重新抛出异常；

歩骤 S907: 将 Umt块释放到线程异常状态控制表的空闲范围块链表；歩骤 S908: 设置异常已处理的状态；

歩骤 S909: 执行异常处理程序代码；

歩骤 S910: 转下一个异常处理方式的 except块或者结束异常处理。

实现代码如下：

#define SEH— EXCEPT— VAR(seh— type— num, seh_type_array,method) \ else \ if(method = = EXCEPTION— HANDLE— METHOD) {\

调用 SEH_ScopeTablePop将 Unit弹出线程异常范围表 \

将 Umt块释放回线程异常状态控制表中的线程空闲范围块链表 \ if (异常现场信息中 ulSehType与 seh— type— array中的类型匹配） \

{\

_try_pSehThCtrl->ulSehStatusFlag = SEH— STAT— HANDLED; \

} \

else \

SEH RETHROWO; \

(3 ) 捕捉和处理某一异常区间内的异常

实现流程如图 10所示，包括：

歩骤 S1001：开始执行 except块宏；

歩骤 S1002:关闭正常处理分支的作用域或前一个异常处理方式的作用域；

歩骤 S1003 : 判断是否是当前异常处理方式，如果是，转歩骤 S1004, 否则，转歩骤 S1010;

歩骤 S1004: 将 Unit块弹出线程异常范围表；

歩骤 S1005: 判断是否匹配异常区间内的异常类型，如果是，转歩骤 S1007, 否则，转歩骤 S1006;

歩骤 S1006: 重新抛出异常；

歩骤 S1007: 将 Umt块释放到线程异常状态控制表的空闲范围块链表; 歩骤 S1008: 设置异常已处理的状态；

歩骤 S1009: 执行异常处理程序代码；

歩骤 S1010: 转下一个异常处理方式的 except块或者结束异常处理。实现代码如下：

#define SEH— EXCEPT— IN(seh— type— min, seh_type_max,method) \ else \ if(method = = EXCEPTION— HANDLE— METHOD) {\

调用 SEH— ScopeTablePop将 Unit弹出线程异常范围表 \

mt块释放回线程异常状态控制表中的线程空闲范围块链表 \

if异常现场信息中 ulSehType与 seh— type— min/max区间的类型匹配） \

{\

_try_pSehThCtrl->ulSehStatusFlag = SEH— STAT— HANDLED; \

} \

else \

SEH_RETHROW();\

} \

此外，本发明实施例还在 except块中提供给应用层做进一歩处理的相关操作宏接口如下：

( 1 ) 获得异常记录信息

#define SEH GET RECORD(pSehRec) \

((pSehRec) = &( _ try _ SehThCtrl->pSehExcInfo.seh_rec))

(2) 获得异常类型

#define SEH— GET— TYPE(SehType) \

((SehType) = _ try _ SehThCtrl->pSehExcInfo.seh_rec.ulSehType)

(3 ) 设置异常嵌套层数

#define SEH— GET— NEST— COU T(NestCount) \

(NestCount) = _try__p SehThCtrl->ulExceptNestCnt

(4) 设置异常处理状态

#define SEH— SET— STATUS(SehStatus) \

_try_pSehThCtrl->ulSehStatusFlag = (SehStatus) 四、 throw块的设计

调用 throw的地方有两处，一处是在系统捕获硬件异常时，调用 throw 块，将异常通知到 except块，另一处则是 try中的函数主动调用 throw抛出软件异常。对这两种情况，这里提供统一的抛出操作， gP，获得线程异常范围表中位于栈顶的存储单元（但不弹出），对单元内容进行赋值，可通过函数 SEH— Throwlnner实现。

实现流程如图 11所示，包括：

歩骤 S1101 : 执行 Throwlnner ( ) 函数；

歩骤 S1102: 判断参数是否合法，如果是，则转歩骤 S1103 , 否则，转歩骤 S1112;

歩骤 S1103 : 获取当前线程异常状态控制表的地址；

歩骤 S1104: 获得线程异常范围链表的栈顶存储单元；

歩骤 S1105: 判断是否有匹配的 try块和 except块，如果是，则转歩骤 S1106, 否则，转歩骤 S1112;

歩骤 S1106: 判断是否有共享异常信息缓存或者抛出的异常记录是否是异常现场记录，如果是，转歩骤 S1107 , 否则，转歩骤 S1111 ;

歩骤 S1107: 分配共享异常信息缓存；

歩骤 S1108: 判断是否有缓存，如果是，则转歩骤 S1109, 否则，转歩骤 S1112;

歩骤 S1109: 初始化缓存，设置未处理异常标志；

歩骤 S 1110：执行 except块代码；

歩骤 S1111 : 设置异常处理标志；

歩骤 S1112: 进行默认的异常处理。

实现代码如下：

void SEH_ThrowInner(VOS_SEH_REC *pSehRec) SEH— SCOPE— UINT *pTempUnit;

SEH— EXC— INFO *pInfoBuf;

SEH— TH— CTRL *pSehThCtrl;

VOS— UINT32 ulSehStatusFlag;

if (VOS— NULL— PTR == pSehRec) 参数非法，按系统默认异常处理 pSehThCtrl =当前线程状态控制表地址

pTempUnit = SEH_ScopeTableTop(pSehThCtrl->pScopeTableHead); if (VOS_NULL_PTR == pTempUnit) 表明没有 try-except块，按系统默认异常处理 if ( (VOS— NULL— PTR == pSehThCtrl->pSehExdnfo)

II (pSehRec！ = & (pSehThCtrl->pSehExcInfo->seh— rec》 plnfoBuf = SEH ExcInfoBufAllocO;

if (VOS— NULL— PTR == plnfoBuf)

{

表明无共享异常信息缓存，按系统默认异常处理 pSehThCtrl->ulExceptNestCnt = 1;

pSehThCtrl->pSehExcInfo = plnfoBuf;

对 *pInfoBuf内容进行初始化

plnfoBuf -〉 seh—rec.ulSehType = pSehRec->ulSehType;

plnfoBuf的其他赋值操作 ...

ulSehStatusFlag = SEH STAT U HANDLE; else ulSehStatusFlag = pSehThCtrl->ulSehStatusFlag;

}

/* longjmp第二个参数用于将异常处理状态信息回传给

pSehThCtrl->ulSehStatusFlag */

longjmp(pTempUnit->seh_env, ulSehStatusFlag); 对程序抛出的软件异常情况，大多数硬件异常信息可以屏蔽。简化后的宏封装接口首先初始化抛出的异常记录信息，然后调用 SEH— Throwlnner函数，实现如下：

#define SEH_THROW(SehType, SehErrCode, SehMsg) \ VOS— SEH— REC tmpSehRec; memset(&tmpSehRec, 0, sizeof(tmpSehRec));

tmpSehRec. ulSehType = SehType;

tmpSehRec. ulSehErrOrlntCode = SehErrCode;

strncpy(tmpSehRec.stSehMsg, SehMsg, 31);

tmpSehRec.stSehMsg[31] = 0;

SEH_ThrowInner(&tmpSehRec);

对于当前 excpet块无法处理的情况，前面已在 SEH— EXCEPT— ONE、

SEH— EXCEPT— VAR和 SEH— EXCEPT— IN的情况下描述，将

pSehThCtrl->ulSehStatusFlag设置为需要进一歩回溯状态

SEH— STAT— CONTINUE— SEARCH后执行 rethrow,重新抛出接口实现如下: #define SEH_RETHROW() \

SEH_ThrowInner( & (pSehThCtrl->pSehExcInfo->seh_rec) )

五、框架精细管理的实现

对框架的精细管理有两个方面。一方面提供对异常抛出时处理模块级别的精细管理，另一方面提供对异常处理方式的精细管理。

( 1 ) 异常抛出时处理模块级别的精细管理

代码抛出异常时，可以根据精细程度查找 try块，为此定义宏

SEH— HANDLE— LEVEL, 用户通过配置该宏可以保存期望的异常处理框架的精细度。该宏的值默认为 FUNC— LEVEL (函数级）。用户可以根据需要将该宏的值配置为 MODULE— LEVEL或者 COMPONENT— LEVEL。

用户在设置 try块保护代码时，同时可以指定 try块的配置级别

SEH LeveL 在 try块的设计中，可以看到，当

SEH—Level>=SEH— HANDLE— LEVEL时，框架中代码抛出异常时相应的 try 块才被识别。因此，在开发的不同阶段，用户只需要配置

SEH— HANDLE— LEVEL, 就可以对异常处理框架的精细度进行控制。例如，用户在调试阶段设置 SEH— HANDLE— LEVEL为 FUNC— LEVEL (函数级别），所有 try块均可被识别；当代码稳定后，用户设置 SEH— HANDLE— LEVEL 为 FUNC— LEVEL为 MODULE— LEVEL,则代码在抛出异常时只识别模块级的异常。

框架对配置的异常处理级别的判断和支持在 try块中实现，其实现和流程在 try块的设计和图 8中已做了说明。

(2 ) 异常处理方式的精细管理

用户在嵌入式 C语言环境下开发的不同阶段，对异常的处理会有不同的处理方式。例如，在开发阶段，对异常的处理主要方法是捕获异常处理错误并输出错误，而在开发完成产品发布时，异常处理的主要方法是容错恢复。因此，异常处理的精细管理为用户提供框架，使得用户在不同阶段编写异常处理代码时，不需要覆盖以前的代码而只是简单的指定处理方式，针对不同的处理方式编写不同的异常处理代码。

为此，可以设置宏 EXCEPTION— HANDLE— METHOD保存用户当前的处理方式，在 except块捕获异常时，指定处理方式 method

(EXCEPTION— CHECK、 EXCEPTION— TOLARENT以及其他用户定义的方式） method与当前的处理方式 EXCEPTION— HANDLE— METHOD相同的 except块才能处理对应 try块的异常。用户可按照如下方式使用异常处理框架：

SEH TRY BEG ( SEH level)

SEH THROW }

SEH— EXCEPT (methodl ) 处理方式 methodl对应的异常处理代码 SEH— EXCEPT (method2) 处理方式 method2对应的异常处理代码

SEH TRY END 对异常处理方法精细管理的支持实现和流程在 except块的设计部分和图 9中已进行了描述。

(3 ) 异常处理框架的精细管理方法

实现流程如图 12所示，包括：

歩骤 S1201：执行保护程序代码的 try块；

歩骤 S1202: 判断当前级别是否不小于用户配置的级别，如果是，转歩骤 S1203 , 否则，转歩骤 S1209;

歩骤 S1203 : 执行需要保护的程序代码；

歩骤 S1204: 判断需要保护的程序代码是否抛出异常，如果是，转歩骤 S1205 , 否则，转歩骤 S1203 ;

歩骤 S1205 : 确定对应的 except块；

歩骤 S1206: 判断是否符合用户设置的异常处理方式，如果是，转歩骤 S1207 , 否则，转歩骤 S1208;

歩骤 S1207 : 执行异常处理程序代码；

歩骤 S1208: 转下一个异常处理方式，转歩骤 S1206;

歩骤 S1209: 忽略当前 try块保护，转歩骤 S1203。

具体的，用户可以配置异常处理级别和异常处理手段。例如，遇到 try 块时，首先判断当前 try块的级别是否不小于用户配置的异常处理级别，如果是，则对代码进行保护，否则，忽略该 try块的保护机制。对于 try块保护的代码，如果抛出异常，则寻找对应的 except块，如果找到的 except块的处理手段与用户配置的处理手段相符，则进行相应的异常处理，否则，寻找相应的下一处理手段的 except块。

六、用户接口及使用方法

本发明实施例提供了两类外部接口：一类是搭建异常框架的接口，包括用于识别代码片段的 try块的接口 SEH— TRY— BEG和 SEH— TRY— END,用于与代码片段匹配的异常处理程序 except块的接口 SEH— EXCEPT (匹配所有异常）、 SEH— EXCEPT— ONE (匹配某一类异常）、 SEH— EXCEPT— VAR (匹配异常类型可变）和 SEH— EXCEPT— IN (匹配特定类型号区间的异常），以及用于抛出异常的 throw块的 SEH— THROW接口；另一类是在异常处理框架中，为方便应用程序进一歩处理异常，或者根据需要更灵活的控制异常处理流程所使用的处理接口，包括 SEH— GET— RECORD (获取异常记录信息）、 SEH— GET— TYPE (获取异常类型）和 SEH— SET— STATUS (设置异常处理状态），上述接口均以宏方式提供，并在异常处理框架内部使用。用户可在代码中通过如下方式使用该异常处理框架：

SEH TRY BEG ( SEH level) //用户想要监控保护的代码

SEH_THROW(SehType, SehErrCode, SehMsg) //如果发生异常，则将其抛出

SEH EXCEPT (异常类型， mothodl )

SEH_GET_RECORD(/*获取异常记录 */);

if (硬件异常）

/*进一歩加工、转储异常信息 */

app_exc_handle()；

if (软件异常) /*进行全面的错误检查及错误信息上报 */

app_err_handle()；

SEH— SET— STATUS (/*可设置为继续回溯异常、从异常指令处恢复执行、复位进程

SEH EXCEPT (异常类型， mothod2)

... ... //其他异常处理方式定义的异常处理方法

SEH TRY END

本发明除提供上述异常处理方法外，还提供了嵌入式 C语言环境下退出线程或进程的方法和删除线程或进程的方法。

退出线程或进程的方法的实现流程如图 13所示，应用于线程主动退出的场景，包括：

歩骤 S1301 : 获得线程或进程需要退出的信息。

歩骤 S1302:检查需要退出的线程或进程所抛出的异常是否仍然占用资源，如果是，转歩骤 S1303 , 否则，转歩骤 S1304;

歩骤 S1303 : 释放所述占用的资源；

歩骤 S1304: 退出所述线程或进程。

检查需要退出的线程或进程所抛出的异常是否仍然占用资源具体可以包括：检查需要退出的线程或进程是否已抛出异常；如果是，则检查已抛出的异常是否仍然占用资源。

具体的，可以为用户提供线程退出的接口操作 VOS— ExitThread, 该接口函数在退出线程前，首先检查当前线程是否有异常处理的资源尚未释放，如果有，则对 try块中抛出异常所占用的资源进行检查和释放，之后执行退出线程的操作。

其中的一种嵌入式 C语言环境下退出线程或进程的装置可以如图 14所示，包括：信息获得单元 1401，用于获得线程或进程需要退出的信息；资源检查单元 1402，用于在信息获得单元 1401获得线程或进程需要退出的信息后，检查需要退出的线程或进程所抛出的异常是否仍然占用资源；资源释放单元 1403，用于在资源检查单元 1402检查出需要退出的线程或进程所抛出的异常仍然占用资源，则释放所述占用的资源；线程或进程退出单元 1404，用于在资源释放单元 1403释放所述占用的资源后，退出所述线程或进程。

删除线程或进程的方法的实现流程如图 15所示，应用于当前线程或进程被其他线程或进程删除的场景，包括：

歩骤 S1501 : 确定需要删除的线程或进程。

歩骤 S1502:检查需要删除的线程或进程所抛出的异常是否仍然占用资源，如果是，转歩骤 S1503 , 否则，转歩骤 S1504;

歩骤 S1503 : 释放所述占用的资源；

歩骤 S1504: 删除所述线程或进程。

检查需要删除的线程或进程所抛出的异常是否仍然占用资源具体可以包括：检查需要删除的线程或进程是否已抛出异常；如果是，则检查已抛出的异常是否仍然占用资源。

具体的，若线程 1抛出异常后切换到线程 2，线程 2需要执行对线程 1 的删除操作，在本发明实施例中，线程 2对线程 1中抛出的异常所占用的资源进行处理后再删除线程 1。

在 Lmux下，线程 2删除线程 1是通过给线程 1发送信号实现的，因此，可以在线程 1中注册信号的处理函数 handler中对已抛出的异常进行处理。在 Lmux下，对于跨进程删除时的异常处理可以采用同样的方法进行处理。

在 VxWorks下，删除任务的函数 taskDelete允许通过函数 taskDeleteHookAddO注册钩子函数，因此，可在删除任务之前，注册钩子函数对要删除的任务的异常进行处理。

对于以上两种操作系统，本发明实施例提供统一的处理手段。具体的，提供 VOS— KillExHandleO函数，在 Linux系统下注册为删除线程（进程）的信号的 handler,在 vxWorks下注册为退出钩子。 VOS— KillExHandleO函数通过获得被删除线程的异常状态控制表中的信息获得当前要处理的异常，然后对异常及其占用的资源进行相应的处理。

其中的一种 C语言环境下删除线程或进程的装置如图 16所示，包括：确定单元 1601，用于确定需要删除的线程或进程；

资源检查单元 1602，用于在确定单元 1601确定需要删除的线程或进程后，检查需要删除的线程或进程所抛出的异常是否仍然占用资源；

资源释放单元 1603，用于在资源检查单元 1602检查出需要删除的线程或进程所抛出的异常仍然占用资源，则释放所述占用的资源；

线程或进程删除单元 1604，用于在资源释放单元 1603释放所述占用的资源后，删除所述线程或进程。

综上所述，本发明实施例实现了在嵌入式 C语言环境下不依赖于编译器的可精细管理的异常处理方法。本发明实施例提供的用户接口可以将用户的编码和异常处理分离，使得用户在使用嵌入式 C语言环境进行程序开发时，通过使用简单的宏接口即可实现基于异常处理的程序设计，从而更关注代码正常分支的开发。对异常框架的可精细管理的设计使得用户可以根据需要调整异常处理的级别，例如，在调试阶段可以将异常处理定在函数级，以尽量抓取程序的异常，而在代码稳定后，产品上网运行时将异常处理级别定为部件级，忽略函数级的异常处理，只针对模块出现的异常进行统一处理。

针对现有技术中用户无法根据自己的需要对异常处理的粒度和方式进行控制的状况，本发明实施例在上述不依赖于编译器的异常处理方法和异常处理框架中实现将异常处理动态配置到函数、模块或者组件的机制，以及配置异常处理的机制，从而实现对异常处理方法和异常处理框架的精细管理。使得用户可以根据自己的需要对异常处理框架和处理方法进行精细管理。用户对异常处理框架和处理方法的精细管理包括两个方面：

一方面，在开发的不同阶段，用户可以根据需要将异常处理动态配置到函数、模块、组件等不同级别，从而达到对异常处理框架的精细管理。例如，在产品开发阶段，用户为了尽量找到引发异常的错误，可以将异常处理级别配置为函数级别，在异常处理保护的代码中，函数抛出的异常都会被函数的异常处理机制捕获并处理；当产品开发结束发布时，代码已经较为稳定，为了提高性能，用户可以将异常处理级别配置为模块级甚至部件级，异常处理的机制在模块或部件范围内起作用，抛出的异常会被本模块或部件的异常处理机制捕获并统一处理。

另一方面，用户对同一段保护的代码可以做不同的异常处理，并可以在异常处理框架中配置异常处理方法，在不同的情况下使不同的异常处理方法生效。例如，对同一段保护的代码，用户的异常处理可以有查错和容错至少两种处理方式，在代码开发时使用查错方式尽量找到引发异常的错误，而在产品发布时使用容错方式对异常进行恢复处理。用户可以在异常处理框架中配置异常处理方式为查错或者容错。

以及，在本发明实施例的嵌入式 C语言环境下异常处理方法、装置及嵌入式系统中，如果程序代码片段出现异常，则不是简单的重新运行程序代码片段，而是使用独立于程序代码片段的异常处理程序来处理异常，这样，程序在运行时，就不会因为异常而中断运行，满足了产品不希望系统运行时发生中断的需求。

以及，针对现有技术中的异常处理机制不支持跨线程和跨进程删除时的异常处理，本发明实施例在嵌入式 C环境下不依赖于编译器的异常处理方法和异常处理框架中提供了线程主动退出和跨线程（进程）删除时的方法。在本发明实施例的嵌入式 C语言环境下退出或删除线程或进程的方法中，无论是退出或者删除线程或进程，都可以释放处理线程或进程抛出的异常所占用的资源，这样，当其他线程或进程需要使用这些资源时，不会因为删除或退出的线程或进程所抛出的异常仍然占用资源而导致其他线程或进程无法使用这些资源。另外，还可以由其他线程删除所需要删除的线程，从而可以实现跨线程删除线程时的异常处理。

本领域普通技术人员可以理解实现上述实施例的嵌入式 C语言环境下异常处理的过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于可读取存储介质中，该程序在执行时执行上述方法中的对应歩骤。所述的存储介质可以如： ROM/RAM、磁碟、光盘等。

最后需要说明的是，本发明所有的实施例都可以应用于嵌入式 C语言环境下、非嵌入式 C语言环境下。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

权利要求书

1.一种嵌入式 C语言环境下的异常处理方法，其特征在于，包括：监控正在运行的需要保护的程序代码片段，如果所述程序代码片段出现异常，则抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常，其中，所述异常处理程序与所述程序代码片段相互独立。

2.如权利要求 1所述的方法，其特征在于，所述监控正在运行的需要保护的程序代码片段的歩骤为：根据设置的处理异常的粒度，监控所述正在运行的需要保护的程序代码片段。

3.如权利要求 1所述的方法，其特征在于，所述方法进一歩包括：申请用于记录与异常相关的信息的存储空间；

贝 |J，在所述程序代码片段出现异常之后，抛出所述异常之前，记录与异常相关的信息。

4.如权利要求 1或 3所述的方法，其特征在于，所述抛出所述异常为：将所述与异常相关的信息打包后传递出去，所述与异常相关的信息至少包括异常类型标识，所述异常类型标识用于表示当前程序代码片段出现的异常的类型。

5.如权利要求 4所述的方法，其特征在于，所述根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常的歩骤包括：获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识；

确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常。

6.如权利要求 5所述的方法，其特征在于，所述确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常的歩骤包括：

或，当所述异常类型标识对应的异常类型与能处理的至少一种异常类型中的一种异常类型匹配时，由与该异常类型匹配的异常处理程序处理该异常；

7.如权利要求 6所述的方法，其特征在于，所述方法进一歩包括：如果当前不存在与该异常类型匹配的异常处理程序时，将获得的与异常相关的信息重新传递出去，或者，当均匹配不上时，启动默认处理程序，所述默认处理程序为重启系统。

8.如权利要求 4所述的方法，其特征在于，所述根据获得的所述异常，确定相应的异常处理程序，由所述异常处理程序处理所述异常的歩骤包括：获得传递过来的与异常相关的信息，所述与异常相关的信息包含异常类型标识和指定处理方式标识；

确定与所述异常类型标识对应的异常类型所匹配，且与所述的指定处理方式标识对应的处理方式所匹配的异常处理程序，由所述匹配的异常处理程序处理所述异常。

9.如权利要求 5所述的方法，其特征在于，所述异常处理程序还能够匹配和处理多种类型的异常。

10.如权利要求 5所述的方法，其特征在于，如果有多个与所述异常类型相匹配的异常处理程序，则确定与所述异常类型标识对应的异常类型所匹配的异常处理程序的歩骤为：

确定与所述异常类型标识对应的异常类型所匹配的，且与所述程序代码片段位置最近的一个异常处理程序。

11.如权利要求 1所述的方法，其特征在于，如果所述程序代码片段被调用时出现异常，则由所述异常处理程序处理所述异常之后，所述方法进一歩包括：逐级返回所述程序代码片段正常运行后的结果，或者运行与所述异常处理程序相邻且在其之后的程序代码片段。

12.如权利要求 2所述的方法，其特征在于，所述设置的处理异常的粒度包括函数级别、模块级别、部件级别中的至少一种，其中，所述模块由多个函数组成，所述部件由多个模块组成。

13.如权利要求 8所述的方法，其特征在于，当所述处理方式是容错处理方式，由容错方式的异常处理程序处理所述异常；

当所述处理方式是查错处理方式，由查错方式的异常处理程序处理所述异常，其中，所述异常处理程序与所述程序代码片段相互独立。

14.如权利要求 1所述的方法，其特征在于，由具有匹配和捕捉异常功能的宏来匹配和捕捉异常；由具有监控功能的宏来监控正在运行的需要保护的程序代码片段；由具有抛出异常功能的宏来抛出所述异常。

15.—种嵌入式 C语言环境下异常处理装置，其特征在于，包括：监控单元，用于监控正在运行的需要保护的程序代码片段；

异常抛出单元，用于在所述监控单元发现所述程序代码片段出现异常后，抛出所述异常，所述异常包括软件异常、硬件异常中的至少一种；匹配单元，用于根据获得的所述异常，确定对应的异常处理程序，所述异常处理程序用于处理所述异常抛出单元抛出的异常，其中，所述异常处理程序与所述程序代码片段相互独立。

16.如权利要求 15所述的异常处理装置，其特征在于，还包括：信息记录单元，用于记录与所述监控单元发现的所述程序代码片段出现的异常相关的信息，并输出给所述异常抛出单元。

17.如权利要求 16所述的异常处理装置，其特征在于，所述异常抛出单元为第一异常抛出单元，用于在所述监控单元发现所述程序代码片段出现异常后，将所述与异常相关的信息打包后传递出去，所述与异常相关的信息至少包括异常类型标识，所述异常类型标识用于表示当前程序代码片段出现的异常的类型。

18.如权利要求 17所述的异常处理装置，其特征在于，所述匹配单元为第一匹配单元，用于获得传递过来的与异常相关的信息，所述与异常相关的信息中包含异常类型标识，并确定与所述异常类型标识对应的异常类型所匹配的异常处理程序，由所述异常处理程序处理所述异常。

19.如权利要求 17所述的异常处理装置，其特征在于，所述匹配单元为第二匹配单元，用于获得传递过来的与异常相关的信息，所述与异常相关的信息包含异常类型标识和指定处理方式标识，并确定与所述异常类型标识对应的异常类型所匹配，且与所述的指定处理方式标识对应的处理方式所匹配的异常处理程序，由所述异常处理程序处理所述异常。

20.如权利要求 15所述的异常处理装置，其特征在于，如果有多个与所述异常的类型相匹配的异常处理程序，所述匹配单元为第三匹配单元，用于根据获得的所述异常，确定与所述异常的类型所匹配的，且与所述程序代码片段位置最近的一个异常处理程序，由所述异常处理程序处理所述异常。

21.如权利要求 15所述的异常处理装置，其特征在于，所述监控单元为第一监控单元，用于在一程序执行触发异常时，根据设置的处理异常的粒度监控所述正在运行的需要保护的程序代码片段。

22.—种嵌入式 C语言环境下退出线程或进程的方法，其特征在于，应用于线程主动退出的场景，包括：

获得线程或进程需要退出的信息；

检查需要退出的线程或进程所抛出的异常是否仍然占用资源；如果是，则释放所述占用的资源；

退出所述线程或进程。

23.如权利要求 22所述的方法，其特征在于，检查需要退出的线程或进程所抛出的异常是否仍然占用资源具体包括：

检查需要退出的线程或进程是否已抛出异常；

如果是，则检查已抛出的异常是否仍然占用资源。

24.—种嵌入式 C语言环境下退出线程或进程的装置，其特征在于，包括：

信息获得单元，用于获得线程或进程需要退出的信息；

资源检查单元，用于在所述信息获得单元获得线程或进程需要退出的信息后，检查需要退出的线程或进程所抛出的异常是否仍然占用资源；

资源释放单元，用于在所述资源检查单元检查出需要退出的线程或进程所抛出的异常仍然占用资源，释放所述占用的资源；

退出单元，用于在所述资源释放单元释放所述占用的资源后，退出所述线程或进程。

25.—种嵌入式 C语言环境下删除线程或进程的方法，其特征在于，应用于当前线程或进程被其他线程或进程删除的场景，包括：

确定需要删除的线程或进程；

检查需要删除的线程或进程所抛出的异常是否仍然占用资源；如果是，则释放所述占用的资源；

删除所述线程或进程。

26.如权利要求 25所述的方法，其特征在于，检查需要删除的线程或进程所抛出的异常是否仍然占用资源具体包括：

检查需要删除的线程或进程是否已抛出异常；

如果是，则检查已抛出的异常是否仍然占用资源。

27.—种嵌入式 C语言环境下删除线程或进程的装置，其特征在于，包括：

确定单元，用于确定需要删除的线程或进程；

资源检查单元，用于在所述确定单元确定需要删除的线程或进程后，检查需要删除的线程或进程所抛出的异常是否仍然占用资源；

资源释放单元，用于在所述资源检查单元检查出需要删除的线程或进程所抛出的异常仍然占用资源，释放所述占用的资源；

线程或进程删除单元，用于在所述资源释放单元释放所述占用的资源后，删除所述线程或进程。

28.—种嵌入式系统，其特征在于，所述系统包括如权利要求 15-21任意一项所述的异常处理装置。