搜档网
当前位置:搜档网 › 第6章Delphi程序异常处理与调试技术.

第6章Delphi程序异常处理与调试技术.

第6章Delphi程序异常处理与调试技术.
第6章Delphi程序异常处理与调试技术.

第六章程序异常处理与调试技术

在Delphi中有两种程序错误,一种是编译错误,在程序编辑阶段就可以由编译器发现并给出提示。另外一种是运行错误,这类错误不能在编译阶段查出,只能在程序执行时发现,称为运行错误。 Delphi提供了一种机制来处理运行错误,保护程序的正常执行,这种机制就是异常处理。异常处理的方法是把正常的执行程序同错误的处理程序分离开来,这样可以保证在没有错误时,程序正常执行,当发生错误时,执行错误处理部分的程序,然后程序跳出保护模块,继续执行后续的程序。

6.1 Object Pascal异常的种类

异常的种类:Delphi内建的异常类,程序员自定义的异常类。

异常基类及其属性和主要方法:在Delphi中,所有异常的基类是Exception 类。所有其他异常类都是由该类派生而来。

1. exception属性

该类有两个基本属性:HelpContext和Message。

(1)Exception.HelpContext属性

该属性的定义如下:

?Type ThelpContext= -MaxLongint..MaxLongint;

?Property HelpContext:ThelpContext;

HelpContext是ThelpContext类的一个实例,它提供了与异常对象联系在一起的上下文相关帮助信息的序列号。该序列号决定当发生异常时用户按F1键显

示的一个异常错误的帮助信息。

(2)Exception.Message属性

该属性的定义如下:

property Message: string

该属性存储异常发生时的错误信息。可以通过该属性在提示错误对话框中显示错误信息字符串。

2.exception方法

(1)Exception.Create方法

该方法的定义形式为:

Constructor Create(Const Msg: String);

该方法用来产生一个带有一条简单提示信息的对话框,对话框中的提示内容由Msg提供

(2)Exception.CreateFmt方法

该方法的定义格式如下:

Constructor CreateFmt(Const Msg:String;Const Args:Array of Const) ;

该方法用来产生一个带有格式化字符串提示信息的对话框,格式化的字符串由Msg和Args数组共同提供,其中数组Args负责提供用于格式化的数值。

(3)Exception.CreatHelp方法

该方法的定义格式如下:

Constructor CreateHelp(Const Msg:String; AhelpContsxt:Integer) ;

该方法产生一个带有一条简单提示信息和上下文帮助序列号的提示对话框。其中Msg参数包含了显示在异常对话框中的运行错误信息。AhelpContext参数包

6.1.1 Delphi内建的异常类

Delphi内建立异常类其标识符的第一个字母都是“E”,如此我们很容易就能辨认出此种类。

6.1.2自定义异常类

自定义的异常类必须继承内建的Exception类,或者继承Exception的某个子类才行。除此之外,自定义异常类的语法和自定义一般类的语法并没有不同。

6.2触发异常的方法

触发异常的方法,主要可分为两种,一种是由程序系统自动触发,一种则是利用raise指令触发.

6.2.1由程序系统自动触发

只要属于Delphi内建类的异常产生时,程序系统就会在当下自动触发它们,并捕捉其信息,然后将异常的信息以对话框显示出来,这些是一般公认的异常状况,即使我们不对这些异常做处理,程序系统也会帮我们做处理,然后让程序再继续执行下去,这样程序就不会在当时异常中断,而出现意料之外的问题。

不过程序系统所作的只是一般的处理,通常仅是避开执行会发生异常的程序代码,而不会排除掉异常发生的原因。故若保持原来的状态再做同样的执行操作,仍旧会触及同样的异常,却无法执行下一步的程序。因此为了让程序执行更顺畅,并且让用户更容易使用我们所开发的应用程序。即使是程序系统自动触发的异常,我们也应该主动去处理,设法去除导致异常的原因。或者给予用户更明确,更人

性化的提示,尽量不要让用户感到任何操怍上的困难,并且避免异常重复发生而浪费不必要的时间。

6.2.2使用raise指令触发

自行触发异常的方式.使用raise指令.其语法如下:

Raise 异常对象实体

不要将raise指令当成一般语句使用,它必须配合异常处理语法来使用。

6.3处理异常情况

专门用来处理异常情况的语句主要有两种,一种是“try_ except_end”结构,另一种则是“try_finally_end”结构。

由于Delphi在程序设计时,提供了调试器(Debugger),因此当程序执行时若发生异常状况,调试器将发挥功能,让程序在异常发生点,并且提示调试的方法,方便找出问题所在。然而这样程序就无法如实展现异常处理的情况,而且这个应用程序若不在Delphi环境下执行,也不会有调试器存在。因此在设计异常处理程序时,点选【Tools】|【Debugger Options】|【General】选项,然后取消【Integrated debugging】选项,这样才能看到异常处理的效果

6.3.1 Try…Finally…End结构

Try…Finally…End结构只需要触发异常,程序系统将自动捕捉被触发的异常,然后以信息对话框显示出异常的信息,让程序避开发生异常的程序代码,然后向下执行程序。

无论在“Try…Finaly”区内是否有异常被触发,都会接着执行“Findly…End”区的语句。然而若是在“Try…Finally”区内有异常产生并被触发时,就会由异常发生点跳转此区域,转而执行“Finally…End”区的所有语句。

例:

procedure Form1.Button1Click(Sender:TO b j e c t ) ;

Var

MyStringList:TStringList;

begin

MyStringList:= TStringList.Create;

try

MyStringList.Assign(ListBox1.Items);

finally

MyStringList.Free;

end;

包括由程序系统自动触发以及程序员使用raise指令去触发的异常,故在本区可根据状况条件来使用Raise指令。然而在本区使用raise指令,或者由程序系统自动触发某些异常时,程序系统并不一定会自动处理这些异常,这时程序就有可能会异常中断,因此需要“Except…End”区中捕捉异常,并且对异常作适当处理;也可仿照“Try…Finally…End”语法,在“Except…End”区对“Try…Except”区内被触发的异常作再次触发(Reraise)的操作,即再次使用Raise指令,由程序系统自动捕捉异常,以信息对话框显示出异常信息,然后让程序避开异常,而不致于中断程序。

6.3.2 “Except…End”区中的语句

在“Except…End”区中,可以有多个语句,但此处主要是放置用来捕捉异常的语句,其目的是让程序仍自行捕捉异常,根据异常的类型决定要做的处理操作,而此种语句也有它特定的语法:

On 异常对象标识符:类型 do //异常对象标识符可有可无

语句;//(on identifier:type do statement)上述语法是表示当指定类型的异常被触发时,就执行保留字“do”后面这个语句。反之若没有这种类型的异常被触发,则不会执行“do”后面的语句。在捕捉异常的语句之后,还可以有一个“Else”区,在这个区域内可以有一般的语句(包括raise指令)。

若本区域内没有“Else”区域时,只要其内有捕捉异常的语句存在,就不允许有一般语句(包括raise指令);倘若本区内若有“Else”区,则除了“Else”区域之外,并不允许有一般语句存在于“Except…Else”区域,否则将导致编译

错误。

6.4 程序调试

Delphi提供了一个功能强大的内置调试器(Integrated Debugger) ,该调试器可以方便地查找程序中出现的运行时间错误和逻辑错误。所谓运行时间错误是指程序能正常编译但在运行时出错。逻辑错误是指程序设计和实现上的错误。

6.4.1调试的准备

1.激活内置调试器

方法是:在Delphi集成开发环境中,选中【Tools】|【Debugger Options】|【General】页的【Integrated Debugging】复选框。默认情况下该框被选中。

2.设置编译和调试选项

默认情况下,Delphi对有些错误和信息不给出调试信息。可改变Delphi默认设置。单击【Project】|【Options】|【Compiler】页。

(1)Runtime Errors区域

Range checking:检查数组或是字符串的下标是否越界,默认时不检测。

I/O checking:检测输入输出错误,默认检测

Overflow checking:整型操作溢出检测,默认不检测。选中该复选框调试器将对整数运算是否溢出做检测,默认下不报告错误。

(2)Debugging区域

设置调试的信息。默认时几乎全部选中。一般无须改变该区域的选项设置。

Debug information:表产生调试信息。如果Debug Information 选中会在单元文件 (.dcu) 中放置调试信息,文件字节变大但不影响速度。

Local symbols:产生局部变量的调试信息。Local Symbols选中会添加与所在类、过程、函数及对象方法中定义的标识符等有关调试信息。在程序调试时调试器会使用这些信息,但这些信息不会添加到可执行文件中。除非在【Project】|【Options】|【Linker】页面中选中【Include TD32 Debug Info】选项,选中了此选项就可以使用TD32来调试。

Reference info/Definitions only:用来产生供Code Browser, Code Explorer and Project Browser使用的标识符引用信息。如果Reference Info和Definitions Only 都被选中,则编译器将记录标识符定义位置信息。如果仅选中了 Reference Info,表示编译器不仅记录标识符定义的位置,同时将记录标识符被引用的信息。如果不选中Debug Information 和 Local Symbols 选项,仅选中该选项将不起作用。

Assertions:产生断言的调试代码。

Use Debug DCUs:使用连接的Dcu文件作为调试路径。必须在【Tools】|【Debugger Options】|【General】页中指定调试文件的路径。一般不选中该项。

(3)Messages 区域

Show Hints:使编译器产生提示信息。例如检测在过程或函数中声明了但一直没有使用的变量信息,或者无效的引用信息等。

Show Warnings:使编译器产生警告信息。

3.编译程序发现编译错误

在调试之前,必须先编译通过。可以选择【Project】|【Complie】 <工程名>可以对工程进行编译,检测编译错误。也可以按【Ctrl+F9】执行同样的操作。默认情况下,如果有错误或是警告和提示信息则显示在Message列表框中。

6.4.2 控制程序的执行

Delphi程序的调试命令都集中在RUN菜单下。可以三种方式进行调试:【Step Over(F8)】单步执行调试、【Trace Into(F7)】跟踪调试或使用、【Run To Cursor (F4)】运行到光标所在处。

Step Over一次执行一行语句,碰到调用过程时也是一步就执行过去,不会跟踪到过程的内部代码中去逐行执行,Trace Into则是在碰到过程或函数时跟踪到它们的内部,可以对其内部代码进行调试。 Run To Cursor则从当前运行位置直接运行到光标所在的位置如果光标所在的位置和当前运行位置处在不同的事件代码中,则不能直接运行到光标处,只有当发生了该事件才可以继续执行。

6.4.3 使用断点

断点(BreakPoint)就是使程序运行中断的点。在一个应用程序总可以设置多处断点,当程序运行到断点处,会暂停执行,等待进一步的命令。

1.断点的设置

(1)单击选定代码行左边的空白。

(2)在光标所在的行处按【F5】。

(3)使用【Run】|【Add Breadpoint】|【source breakpoint】打开断点编辑对话框,在Line Number处输入需要加断点的行号即可。

断点必须位于可执行代码行上,另外,断点既可以在设计状态下设置也可以在运行调试状态下设置。

一个有效(Enable)的断点默认的情况下该代码行显示为红色,正确的断点小圆点中是一个对号。

2.断点的删除和设置

删除一个断点,只要再次在已经设置为断点的代码行单击其左侧的空白处或按【F5】键就可以删除断点。

如果一个应用程序许多位置都设置了断点,则可以使用断点列表框来管理所有的断点。

使用【View】|【Debug】|【breakpoints】打开断点列表框,列表框将列出应用程序中设置的所有断点,无效(Disable)的断点前面的标志为灰色。在列表窗口中单击右键,将显示一个断点设置快捷菜单,使用该快捷菜单可以实现对断点的添加、删除、使有效以及无效等操作。

(1)利用断点列表窗口可以快速找到断点在源代码中的位置

(2)断点功能的失效和恢复

在断点列表窗口单击右键,在快捷菜单中取消对Enable的选择或选择【breakpoints】|【Disable All BreakPoints】项可以使当前选中断点或所有断点失去功能。

快捷菜单中的【Enable BreakPoint】和【Enable All BreakPoint】可以使相应断点恢复功能。同样快捷菜单中的【Delete BreakPoint】和【Delete All BreakPoint】可以删除当前选中断点或所有断点。

3.修改断点属性

在断点列表窗口选择断点后单击右键,在弹出的快捷菜单中选择Properties,则打开断点编辑对话框,用于显示和修改断点属性。

也可以使用【Run】|【Add Breadpoint】|【source breakpoint】打开该对话框。利用该对话框可以改变断点的位置,设置断点条件。断点条件包括两种:

Condition编辑框用于设置布尔表达式条件。如果表达式值为真(或非零)则程序运行在断点处中止;否则调试器将忽略该断点。

Pass Count编辑框用于设置通过次数条件,即只有当程序运行在该断点处通过设定次数时程序运行才在该断点处中止。

同时设置时,Pass Count是指满足条件的通过次数。

6.4.4 监视数据的值

1.监视表达式

选择【View】|【Debug Windows】|【Watches】可以打开监视列表窗口Watch List。在该窗口中单击鼠标右键,在弹出的快捷菜单中选择Add Watch打开监视属性对话框,可以添加新的变量或表达式。也可以使用【Run】|【Add Watch】打开监视属性对话框。

在Expression右边的编辑框中添加要监测的变量或表达式,同时设置其属性。当该表达式代表一个数据元素时,可以在Repeat count中指定其重复次数。如果要监测的是一个数组的值,可以使用Repeat count指定数组元素的下标。

2.计算/修改表达式

选择【Run】|【Evaluate/Modify】可打开计算/修改对话框。

当单击Evaluate按钮时,Expression编辑框中表达式的值显示在Result域中。

Expression中可以输入或选择任何合法的表达式(包括对象的属性),但不能包括;

(1)包含有当前执行点不能引用的局部或静态变量的表达式;

(2)函数或过程调用。

Expression中的表达式可以带特定的格式字符用于规定其显示格式。

其表示语法格式为:变量名,格式字符串。

可使用的格式字符及其功能如下:

?H,X:以十六进制格式显示整型值

?D:以十进制格式显示整型值

?C:把ASCII码在0..31的特殊字等显示为ASCII码图形

?Fn:用n个有效数字显示浮点数

?nM:以十六进制方式显示一变量的内存转储值,n限定要显示的字节数。

?P:以段和偏移量格式显示指针。两部分皆为四位十六进制值

?Modify按钮可以修改特定表达式的值。一般修改表达式的值常用于验证错误解决方案的正确性。在Expression编辑框中输入欲修改的表达式,单击Evaluate按钮观察表达式的当前值。而后在New Value编辑框中输入或选中一个新值,单击Modify按钮确认并更新数据项。但一般不要修改指针和数组下标

?单击Watch按钮可以打开监视列表窗口,并添加选定的表达式到列表窗口中。

?单击Inspect 按钮可以为选择的数据元素打开一个信息的窗口,这对于观测数据结构、类和数组的值特别有用。

3.函数调用

?选择【View】|【Debug Windows】|【Call Stack】可以显示调栈窗口(Call Stack Window)。调栈窗口的顶端列出了应用程序最近的函数调用。

于特定函数调用处的源代码。

4.观测局部变量

当调试的程序位于某一个过程或函数内部时,可以选择View|Debug Windows|local variables可以打开局部变量显示窗口。该窗口显示在该过程或函数内部使用的所有局部变量及其值。

品质异常处理流程模板

品质异常处理流程 (公开文件,共4页) 一、目的: 规范品质异常处理流程,提高品质异常处理的时效性,确保来料质量及生产的正常运转,同时满足顾客的质量要求。 二、范围: 适用于本公司来料、制程、出货品质异常的处理。 三、定义: 3.1 来料品质异常: a、不符合相关检验标准要求,且不良率超过质量目标时; b、合格物料制程中发现重点物料不合格时; c、有经过改善且有效果确认,但又重复发生品质异常时。 3.2 制程品质异常: a、使用不合格的原料或材料; b、同一缺陷连续发生; c、不遵守作业标准或不遵守工艺要求; d、机械发生故障或精度磨损; e、其他情形影响到产品质量时。 3.3 出货品质异常: a、客户投诉或抱怨; 四、职责 4.1 来料品质异常: 品质:a.负责填写《品质异常联络单》“异常描述”部分; b.负责将《来料检验报告》、《品质异常联络单》发送于采购,抄送工程、生产; c负责品质异常改善结果确认。 采购:负责将《来料检验报告》、《品质异常联络单》发送给供应商并及时与供应商联系跟踪供应商及时回复“原因分析”“纠正与预防措施”并将结果回复品质部. 4.2 制程品质异常: 品质部: a,负责品质异常之最终判定; b,负责确认品质异常责任部门; c,负责主导品质异常案例的处理过程; d,负责对责任单位的改善结果进行追踪确认

异常责任单位: a负责品质异常的原因分析,提出临时措施及长期改善对策并执行。 生产部: a负责品质异常的改善和预防措施的实施及验证改善措施的有效性; 其它相关单位: a在需要时进行异常改善的配合 4.3 出货品质异常: 品质部: a负责将品质异常通知各部门及确定责任部门; b负责异常改善后的跟踪确认; c负责处理客户抱怨 异常责任单位: a负责品质异常的原因分析,提出临时措施及长期改善对策并执行。 生产部: a负责品质异常的改善和预防措施的实施及验证改善措施的有效性; 营业部: a负责将客户抱怨反馈给相关部门。 其它相关单位: a在需要时进行异常改善的配合 五、工作程序: 5.1 进料品质异常: 5.1.1 依相关检验标准判定不合格,针对不合格物料标示“不合格”,并立即移至不良品区域。 5.1.2 异常成立4小时内开立《品质异常联络单》通知采购。 5.1.3 采购接《品质异常联络单》后4小时内转责任供应商。 5.1.4 供应商需于1个工作日内针对异常物料提出临时对策,如对异常内容有疑问,需在4 小时与品质相关人员确认清楚。 5.1.5 供应商必须在《品质异常联络单》要求的期限前(如无明确要求,默认为《品质异常联络单》发出后2个工作日内)回复完整的改善方案。 5.1.6 品质部对供应商回复内容进行确认,针对改善措施不合格部分予以退件,要求供应商重新回复。改善措施合格,则报告予以归档,跟踪后续进料品质状况,依5.1.7执行。 5.1.7 针对供应商改善后产品加严检验,连续追踪3批无异常予以结案,转正常检验;连续追踪3批中途发现不良现象仍存在,则重复5.1.2-5.1.7。 5.1.8 如供应商改善措施回复后连续2个月无进料,则强制结案,后续进料依正常检验执行。 5.1.9

产品质量异常处理流程精

供应商来料异常管理流程 1. 目的: 规范来料产品的异常处理流程控制,提高来料合格率。 2. 范围: 本规范适用于所有外购零部件及外包加工件。 3. 职责与权限: 3.1生技部:负责检测治具的制作。 3.2质量中心:负责来料异常的提出、分析、处理。 3.3生产部:负责来料异常协助处理。 3.4研发部:负责来料异常的分析、处理。 3.5生管部:负责确认来料品上线使用时间。 3.6采购部:负责来料异常与供应商的纠通取得异常的处理。 4. 名词定义: 4.1不合格:未满足产品的质量要求。 4.2 A类:单位产品的极重要质量特性不符合规定,或者单位产品的质量特性极严重不符合规定。 4.3 B类:单位产品的重要质量特性不符合规定,或者单位产品的质量特性严重不符合规定。 4.4 C类:单位产品的一般质量特性不符合规定,或者单位产品的质量特性轻微不符合规定。 5、异常处理流程控制 5.1 IQC依据检验指导书、封样、评估报告等资料检验,发现来料品不满足质量要求。 5.2 IQC将自已判定为不合格的产品经工程师、部门主管核对确实为不合格品。 5.3 IQC 立即填写《供应商异常矫正单》进行处理。 5.4 质量中心主管主导组织针对异常讨论,参与人员:采购、PIE、质量中心经理、研发工程师、研发总监、厂部厂长及其相关人员。 6、异常分类: 6.1 外观不良:表面有划痕、水印、字体不清、表面气泡、砂眼、黑点、缺料、油污、毛刺、变形、色差、氧化及电镀层脱落、标识规格错误、无料号贴纸、无出厂检验报告等。 6.2性能不良:尺寸与图纸不符、适配过大,过小、色温,波长,亮度不符、电压,电流不符等。 7、异常处理方式 7.1将不良品返回供应商进行返工、返修、报废等。

程序设计异常处理机制

异常处理是程序设计中一个非常重要的方面,也是程序设计的一大难点,从C开始,你也许已经知道如何用if...else...来控制异常了,也许是自发的,然而这种控制异常痛苦,同一个异常或者错误如果多个地方出现,那么你每个地方都要做相同处理,感觉相当的麻烦!Java 语言在设计的当初就考虑到这些问题,提出异常处理的框架的方案,所有的异常都可以用一个类型来表示,不同类型的异常对应不同的子类异常(这里的异常包括错误概念),定义异常处理的规范,在1.4版本以后增加了异常链机制,从而便于跟踪异常!这是Java语言设计者的高明之处,也是Java语言中的一个难点,下面是我对Java异常知识的一个总结,也算是资源回收一下。 一、Java异常的基础知识 异常是程序中的一些错误,但并不是所有的错误都是异常,并且错误有时候是可以避免的。比如说,你的代码少了一个分号,那么运行出来结果是提示是错误https://www.sodocs.net/doc/d19539026.html,ng.Error;如果你用System.out.println(11/0),那么你是因为你用0做了除数,会抛出https://www.sodocs.net/doc/d19539026.html,ng.ArithmeticException的异常。 有些异常需要做处理,有些则不需要捕获处理,后面会详细讲到。 天有不测风云,人有旦夕祸福,Java的程序代码也如此。在编程过程中,首先应当尽可能去避免错误和异常发生,对于不可避免、不可预测的情况则在考虑异常发生时如何处理。Java中的异常用对象来表示。Java对异常的处理是按异常分类处理的,不同异常有不同的分类,每种异常都对应一个类型(class),每个异常都对应一个异常(类的)对象。 异常类从哪里来?有两个来源,一是Java语言本身定义的一些基本异常类型,二是用户通过继承Exception类或者其子类自己定义的异常。Exception 类及其子类是Throwable的一种形式,它指出了合理的应用程序想要捕获的条件。 异常的对象从哪里来呢?有两个来源,一是Java运行时环境自动抛出系统生成的异常,而不管你是否愿意捕获和处理,它总要被抛出!比如除数为0的异常。二是程序员自己抛出的异常,这个异常可以是程序员自己定义的,也可以是Java语言中定义的,用throw 关键字抛出异常,这种异常常用来向调用者汇报异常的一些信息。 异常是针对方法来说的,抛出、声明抛出、捕获和处理异常都是在方法中进行的。 Java异常处理通过5个关键字try、catch、throw、throws、finally进行管理。基本过程是用try语句块包住要监视的语句,如果在try语句块内出现异常,则异常会被抛出,你的代码在catch语句块中可以捕获到这个异常并做处理;还有以部分系统生成的异常在Java运行时自动抛出。你也可以通过throws关键字在方法上声明该方法要抛出异常,然后在方法内部通过throw抛出异常对象。finally语句块会在方法执行return之前执行,一般结构如下: try{ 程序代码 }catch(异常类型1 异常的变量名1){ 程序代码 }catch(异常类型2 异常的变量名2){ 程序代码 }finally{ 程序代码 } catch语句可以有多个,用来匹配多个异常,匹配上多个中一个后,执行catch语句块时候仅仅执行匹配上的异常。catch的类型是Java语言中定义的或者程序员自己定义的,表示代

DSP调试及烧写和加载常见错误及分析

Error: Read status value 0x0001 from symbol PRG_status Flash algorithm failed during clear operation 开始可以正常烧写的,但是上机调试了一下就不能写了. 在烧写lf2407内部flash时出现如下错误,不知是什么原因造成的? Error:Read status value 0x0001 from symbol PRG_status Flash algorithm failed during clear operation. 换了一个芯片后正常 之前有一次在试CCS功能时,一不小心点了一次加密,还没有执行完,就马上点了解密,大概这样烧坏了吧! 太脆弱了,再也不敢试加密了 CMD文件要避开FLASH的40H--44H区间, 我也出现过这样的问题,烧写2407A的片内flash时会出现下面的错误提示:Error: Read status value 0x0001 form symbol PRG_status Flash algorithm failed during clear operation 后来换了一块2407就能烧写了。 是不是2407的flash坏了?有没有办法检测或者修复flash? 昨天在网上查了一下,很多人都遇到了这种问题,可能是dsp内部flash烧坏了吧! 今天重新换了一块芯片,可以烧录进去了,但是上拿到样机上调试一下,再烧录就出现了同样的问题,估计又是flash坏了,到底是什么原因引起的?是不是电源引起的呢? 我也出现过能仿真,但不能烧写的情况!解决方法: 解决方法:降低时钟频率。点击FLASH插件上的“View Config File”,打开VAR.h文件。将该文件中的“PLL_PATIO_CONST .Set 0000h”改成 “PLL_PATIO_CONST .Set 0200h”存盘后,执行目录下的Buildall.bat批处理文件。再重新启动CCS及FLASH插件。 请教高手:在烧写程序的时候出现如下错误:Error: Read status value 0x0001 from s ymbol PRG_status Flash algorithm failed during clear operation

品质异常处理控制程序

目录 1.目的 (3) 2.适用范围 (3) 3.用语定义 (3) 4.参考文件 (3) 5.职责分工 (3) 6.业务流程图 (3) 7.业务流程说明 (3) 7.1 报警 (3) 7.2停产(恢复)标准 (3) 7.3让步申请及签字权限 (6) 7.4质量存档 (6) 8 流程KPI (9) 9. 附录 (10)

1.目的 完善质量反馈信息流程,使每个问题的反馈都能得到有效改善,便于异常质量信息的分析、整改,做好纠正预防措施,杜绝批量质量事故的发生,减少质量事故造成的损失,同时满足顾客的质量要 求。 2.适用范围 3?用语定义 无 4?参考文件: 《质量异常报警流程》、《停产恢复流程》、《让步申请流程》 5.职责分工 5.1质量部:负责质量信息的跟进和相关责任部门回复的整改措施进行跟进; 5.2生产部: ①负责开立影响生产现场正常进行的《品质异常信息报警单》,并负责追踪相关责任部门进行措施回复; ②负责其他部门开立的有关生产《品质异常信息报警单》进行措施回复,并要跟进行措施的验证; ③还要负责保存本部门开立的且相关责任部门回复合格的《品质异常信息报警单》及相关质量记 录; 5.3品质处: ①IPQC负责对产品的过程进行监控; ②QA负责对产品的出货进行质量检验控制; 5.4质量督办负责统计现场、出货及工序前5位问题,由现场PE牵头组织处理,并制定改善行动措施; 5.5开发、质管、工艺:等职能部门负责确认不良问题点,分析不良的根本原因,出具纠正/预防的 控制措施,如出现意见冲突,上诉一级申辩,或由事业部长定裁; 6.业务流程图: 后附 7.业务流程说明: 7.1报警: 7.1.1质量体系中出现不符合问题时由TCE&G或发现部门下达《体系纠偏单》并由质量革新部负责跟踪验证,并保存《体系纠偏单》及相关质量记录;

c#中程序异常处理

第五讲异常处理 教学要求: 1.理解异常处理的概念 2.掌握异常处理的方法 教学学时: 2H 例1. 编写一个应用程序,要求用户通过两个文本 框输入两个数,并求它们的和,并在标签框中输 出。 1. 界面设计 新建一个项目,选择windows应用程序模板, 在窗体上添加三个标签框,两个文本框和一个命 令按钮,如图所示。 2. 设置属性 先将两个文本框改名为txtA和txtB,将输出 结果的标签框改名为labC,再设置各对象的属性如 下: 双击确定命令按钮,进入代码编辑窗口,在自动生成的程序模块 private void button1_Click(object sender, EventArgs e) { } 中输入以下代码: int a, b,c; a = Int32.Parse(txtA.Text); b = Int32.Parse(txtB.Text); c = a + b; labC.Text = "计算结果为:"+txtA.Text + "+" + txtB.Text + "=" + c.ToString(); 4.运行程序 测试程序结果是否正确。 例2. 异常处理。 在程序测试时,输入一个小数,或输入一些字符,程序出现异常并中止运行。 C#中提供了异常处理的机制方法为:

通过try语句捕获异常,通过catch语句处理异常,通过finally语句完成程序的善后处理(如收回已分配的资源,关闭与数据源的连接等),通过throw语句抛出自定义的异常。 try { int a, b, c; a = Int32.Parse(txtA.Text); b = Int32.Parse(txtB.Text); c = a + b; labC.Text = "计算结果为:" + txtA.Text + "+" + txtB.Text + "=" + c.ToString(); } catch { MessageBox.Show("请输入正确格式的整数!"); } 例3. 处理多个异常 在测试以上程序时,若输入一个很大的整数,程序的异常提示信息不够准确。C#提供了处理多个异常的方法。 try { int a, b, c; a = Int32.Parse(txtA.Text); b = Int32.Parse(txtB.Text); c = a + b; labC.Text = "计算结果为:" + txtA.Text + "+" + txtB.Text + "=" + c.ToString(); } catch (FormatException x) { MessageBox.Show("请输入正确格式的整数!"); } catch (OverflowException x) { MessageBox.Show("输入整数不能太大!"); } 例4. 进一步提高 FormatException x中的变量x的作用,及MessageBox.Show()方法的重载。 try { int a, b, c; a = Int32.Parse(txtA.Text); b = Int32.Parse(txtB.Text); c = a + b; labC.Text = "计算结果为:" + txtA.Text + "+" + txtB.Text + "=" + c.ToString(); } catch (FormatException x)

ccs33中建立-编译-调试工程及常见错误讲解.

Part1:ccs3.3中新建一个DM6437的示例工程 1、连接好板子,将板子上仿真器的usb口插到电脑上,启动ccs后,ccs会去获取板子信息并在打开的文件目录中自动生成一个文件,如图所示:笔者使用的是6437的板子 2、用file-new选择建立一个dsp/bios文件 在打开的对话框中选择你使用的板子的型号,如下图: 3、这个时候ccs为我们建立了一个bios文件,以图表显示,里面按照所选板子的类型添加相应的硬件和其他模块。保存这个文件到工程目录下先,文件类型为tcf。 4、保存这个文件的同时,ccs按照bios中的配置在当前目录下自动生成了一个cmd文件。此时将tcf文件和这个cmd文件同时添加到工程中,使用 5、然后需要修改一个编译选项,点击下图所示选项进去:

6、打开后在编译选项对话框总会看到一个命令行,其中最后一句是-mv6400,因为用的是6467的板子,所以这个选项要修改成-mv64+;否则编译会报错:编译选项不正确;但并非所有类型的板子都要改,这个只针对型号为64+的板子。 7、file-new-source file建立一个c源文件,保存并加入到工程中。 以下是示例程序: #include #include #include Int main(Int argc, String argv[])//main函数的类型必须这样写 { unsigned int i; unsigned int sum=0; for(i = 0; i<=100; i++ ) {

sum += i; } printf("the sum = %d .\n",sum); printf("the program run over!\n"); printf("the program run over!\n");} 注意:1)如果想要printf正确输出信息,需要添加对应平台的rts64plus.lib文件。这里是64+平台所以是在C:\CCStudio_v3.3\C6000\cgtools\lib目录下的rts64plus.lib文件,否则ccs 会提示如下警告和错误: >> warning: entry point symbol _c_int00 undefined undefined first referenced symbol in file --------- ---------------- _printf E:\\WorkContent\\projectExample\\Test\\Debug\\test.obj >> error: symbol referencing errors - './Debug/Test.out' not built 2)如果想要printf正确输出信息,cmd文件中必须指定heap的大小,即cmd文件这样写: -c -stack 0x00001000 /* Stack Size */ -heap 0x00001000 /* Heap Size */ //前面这三项必不可少 MEMORY { L2RAM: o = 0x10800000 l = 0x00020000 DDR2: o = 0x80000000 l = 0x10000000 } SECTIONS { .bss > L2RAM .cinit > L2RAM .cio > L2RAM .const > L2RAM .data > L2RAM .far > L2RAM .stack > L2RAM .switch > L2RAM .sysmem > L2RAM .text > L2RAM .ddr2 > DDR2 }

异常处理流程

异常处理流程及注意事项 1.发现不良; (1)确认所采用标准的完整性和有效性; (2)熟练掌握检验所涉及之相关标准或其他文件; (3)严格按抽样标准取样,注意均匀,来料检验须注意来料的不同时间,批号,生产班次等; (4)了解以往的品质状况及其品质履历; (5)掌握品管之检验技巧; 2.标示,区分,隔离; (1)标示,隔离须涉及到具体的不良品和可疑批次,不合格标示要完整且必要时要口头或书面知会先相关人员,以避免他人 混淆误用为原则; (2)不合格标示,隔离须注明不合格原因,检验员,检验日期,进料检验另须注明检验单号,并知会相关人员; 3.初步分析判断,并知会相关单位及现场领导; (1)确定不良等级,异常比率,影响度和影响面,必要时须及时知会相关单位之人员; (2)针对制程或成品类异常,要及时研拟临时对策; (3)进料之异常可能涉及组装或功能之不良,需通过试组装来确定其严重性和影响度,必要时可请工程部帮忙确认; 4.异常提报; (1)异常提报时要注意时效性和准确性,异常单的填写需准确完

整,成品异常要确认追溯批号,PO#与数量; (2)须标示和提供不良品; (3)会签的填写和勾选须正确完整; 5.跟催各相关单位签单状况,根据会签结果处理异常; (1)品管必须跟催会签状况,有迟迟未签之单位必须及时跟催,如多次跟催无效,可请领导协助,以避免异常处理的时效; (2)有签核S物料时,按S物料作业流程处理,并将处理结果维护到异常单中; (3)当物料急上线,且部门领导有同意采用,而高级主管又不在厂内,无法立即签核S单时,可询问品质经理,先输S物料, 以便后续作业; (4)当会签单位处理意见不一致时,需反映部门领导,并确认最终处理结果; 6.确认处理结果; (1)全检或重工后的,需重新确认品质状况,成品类有拆箱之异常,需填写成品不合格处置报表; (2)S物料须对其品质进行跟踪,有异常要及时提报; 7.追踪改善措施; (1)注意改善措施回文必须由责任单位之领导签核,并且要在7个工作日内完成改善措施回文; 8.确认改善结果; (1)评估改善措施之有效性,必要时须修改相关品质系统文件或

异常情况处理制度及流程

山西煤炭运销集团 蒲县昊锦塬煤业有限公司异常情况处理制度为认真贯彻落实国家、省、市关于集中开展安全生产大检查的工作安排要求,加强我矿信息监控系统管理水平,做好矿井生产过程中井下环境参数的有效监控,保障矿井安全生产,加强煤矿安全生产管理水平及抗灾能力,特制定本矿异常情况处理制度如下: 一、值班人员按《中心岗位责任制》规定,浏览查询煤矿安全信息,发现异常情况及时处理,并认真填写《异常情况报告处理表》,传真至县监控中心。 二、监控室值班人员发现系统发出异常报警后,值班人员必须立即通知监控室主任、分管领导,同时立即通知矿井调度部门,由监控室主任或分管领导组织相关人员对本次异常报警进行原因分析,并按规定程序及时报上一级网络中心。处理结果应记录备案。调度值班人员接到报警、断电信息后,应立即向矿值班领导汇报,矿值班领导按规定指挥现场人员停止工作,断电时撤出人员。处理过程应记录备案。当系统显示井下某一区域瓦斯超限并有可能波及其他区域时,矿井有关人员应按瓦斯事故应急预案手动遥控切断瓦斯可能波及区域的电源。值班人员接到网络中心发出的报警处理指令后,要立即处理落实,并将处理结果向网络中心反馈。 当工作面瓦斯浓度达到报警浓度时,值班人员应立即通知矿值班领导及监控室主任,并填写异常情况处理报告表传真上报至

县监控中心;由分管领导或监控室主任安排相关人员进行原因分析,按照瓦斯超限分析原则:①按人工检测值与甲烷传感器对比分析;②按报警地点的历史曲线对比分析;③按报警地点上风侧检测值对比分析。根据分析结果立即将处理措施下达至矿调度中心按处理措施严格执行。报警期间要采取安全措施,报警消除后将报警的起止时间、分析报告、采取措施和处理结果上报县监控室并存档备案。 三、当煤矿通讯中断、无数据显示时,值班人员要通过传真(或电话)向县监控中心报告,并查明原因,恢复通讯。情况紧急的,由值班人员立即向矿领导汇报,对因故造成通讯中断未及时上报的,要通过电话联系移动公司或长途线务局进行抢修。

程序调试与常见程序错误

程序调试与常见程序错误 目录 一、在Codeblocks中调试程序 (1) 二、存储路径设置问题 (4) 三、修改Codeblocks的设置 (4) 四、提示程序无法调试问题 (6) 五、常见错误分析 (6) 六、程序出错的三种情况 (18) 七、常用的纠错方式 (19) 一、在Codeblocks中调试程序 1.注意事项 不允许工程路径中含有空格、汉字。 2.在相应行号后面点击鼠标左键设置断点 3.打开W ATCHS窗口

4.点击调试按钮 5.可以再watchs窗口看到自动变量。黄色三角表示程序暂停的位置

6.通过单步运行按钮进行单步运行。 7.也可以在debuger标签,command栏输入调试命令进行单步运行、打印变量值等操作。 8.程序运行

二、存储路径设置问题 1. 如果不是默认安装路径,code blocks 就无法找到编译器和调试器,就会出现此类问题。 解决办法:Settings——Compiler and debugger——Toolchain executables——Auto-detect。 2. 输出信息为“某个命令执行失败或异常终止”。 解决方法:通常是相应的编译器找不到,试着将其所在路径放到path环境变量中去。 3. 输出编译错误,如某某文件找不到之类。 解决方法:在项目中设置选项中加上路径(通常可利用customer variable项)。 4. 在调试程序的时候弹出类似""XYZ - Debug": The compiler's setup (GNU GCC Compiler) is invalid, so Code::Blocks cannot find/run the compiler. Probably the toolchain path within the compiler options is not setup correctly?! Goto "Settings->Compiler and debugger...->Global compiler settings->GNU GCC Compiler->Toolchain executables" and fix the compiler's setup. Skipping... Nothing to be done (all items are up-to-date)."这种警告。 解决方法:这个错误提示已经说得很清楚了, 找不到编译器, 到菜单Settings->Compiler and debugger...->Global compiler settings->GNU GCC Compiler->Toolchain executables下去修复编译选项前提是你已经装了gcc 如过没装, 就去下个包含mingw的codeblocks, (mingw包含gcc编译器); 三、修改Codeblocks的设置 1.

制程异常控制程序(含表格)

制程异常控制程序 (IATF16949/ISO9001-2015) 1.目的 为确保制程异常得到及时有效地解决,以使生产顺利进行,进而保证质量特制定本程序。 2.适用范围 适用于从物料投入开始到成品包装完成的整个生产过程。 3. 职责 3.1 生产部 3.1.1 生产部现场管理人员职责 1) 异常问题提出,做好不合格品的标识和统计; 2)严格按照处理对策执行; 3)人为作业造成异常的改善; 3.1.2 生产部PQC职责 1)异常问题的确认,制程异常通知单的发出,不合格或异常品的标识; 2)负责制程异常改善对策确认及其效果追踪,制程异常通知单的归档; 3)严格管控ECN的切入及其效果的追踪;

4)改善对策之效果确认、制程异常通知单的归档。 3.2 工程部 3.2.1主导制程异常的分析、解决; 3.2.2负责对异常问题分析、定性、归属责任; 3.2.3综合责任部门改善对策提出综合解决对策(包括临时对策,长期预防改善对策); 3.2.4反馈相关分析和对策、通报《制程异常分析报告》并归档。 3.3 品管部QE、IQC职责 3.3.1来料不良而造成的制程异常问题的分析; 3.3.2监督厂商回复改善对策并追踪和进行效果追踪。 3.4 研发东莞评测实验室职责 3.4.1对物料问题的处理提供判定依据。 4. 制程异常处理流程 4.1制程异常处理流程:附件1 4.2物料不良处理流程:附件2 注1:工程部通过现场分析和试验对问题定性,定性的过程包括对不良率、问题属性、责任归属等情况的判定。

注2:原材料不良包括外观不良、机构尺寸不良、原材料电气功能设计缺陷;研发设计不良包括软硬件匹配性、兼容性问题;制造工艺问题包括生产流程安排不当、作业方法不当造成物料的损害;人为作业问题包括未按照作业指导书作业、人员未经培训直接上线造成物料的损害等。 注3:工程部产品组初步分析,在4小时内给出临时对策(包括在线异常品、已入库异常品的处理)。 注4:责任部门根据问题性质分析问题产生原因,提出纠正措施和长期预防对策; 分析部门主要包含工程部、生产部、品管部、研发东莞评测处。 注5:PQC对临时对策、纠正和长期预防对策的执行结果进行追踪。若有效,继续正常生产;若无效,反馈到相关部门重新确认、分析问题。 5. 引用文件 5.1《PQC制程异常通知单》 5.2《制程异常分析报告》 5.3《生产部生产过程控制程序》 5.4《过程检验控制程序》 6.记录表格 6.1制程异常通知单 制程异常通知单.d oc

异常管理程序

XXXXXXXX有限公司 异常管理程序 文件编号: 版本: 编制: 审核: 批准: XXXXX有限公司发布

异常管理程序 1.目的 为明确和规范公司在各种异常事件发生时相关部门及人员的作业职责和应对措施,确保产品生产、产品交付、公用事业等活动的正常进行。 2.范围 本程序规定了公司异常管理的各项控制要求。本程序适用于品质异常和公用事业异常的处理。 3.规范性引用文件 下列文件对于本文件的应用是必不可少的,凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)使用于本文件。 《进料检验管理办法》 《设备控制程序》 《工装管理办法》 《过程检验管理办法》 《OQC终检控制程序》 《内部不合格品处理程序》 《XXX集团计算机软硬件日常维护管理办法》 《物流管理控制程序》 《采购管理业务程序》 《生产过程控制程序》 《生产计划控制程序》 4.定义 下列定义适用于本标准 4.1异常:超出正常的现象,它包括设备异常、作业异常、产品异常、公共事业异常、其他异常等各种异常情况。具体参见附录1 5.职责

5.1质量管理部负责: 5.1.1确认不良以及发生影响程度(判断可否修复、特采) 5.1.2监督、验证、跟进改进对策及有效性; 5.2制造中心负责 5.2.1操作者负责发现异常时停止操作报告组长等待指示; 5.2.2线组长负责异常状况的确认以及报告提出; 5.2.3主管负责对发生异常情况的分析,确定责任部门并通报和报告质量管理部以 及相关领导。 5.3其他部门负责分析原因,采取临时对策,制订长期改进对策,检讨相关类似不 良的发生。 6.工作流程图(无) 7.文件描述:

C语言程序编辑或调试中常见的错误

常见错误和程序分析 (1)忘记定义变量。例如: void main() { x=3; y=6; printf(“%d\n”,x+y); } C要求对程序中用到的美一个变量都必须定义其类型,上面程序中没有对x,y 进行定义。应在函数体的开头加int x,y; (2)输入输出的数据类型与所用格式说明符不一致。例如,若a已定义为整数,b已定义为实型: a=3;b=4.5; /*对a和b赋值*/ printf(“%f %d\n”,a,b); 编译时不给出出错信息,但运行结果将与原意不符,输出为0.000000 16402它们并不是按照赋值的规则进行转换(如把4.5转换为4),而是将数据在存储单元中的形式按格式符的要求组织输出(如b占4个字节,只把最后2个字节中的数据按%d作为整数输出)。 (3)未注意int型的数据的数值范围。Turbo C等编译系统,对一个整型数据分配2个字节。因此一个整数的范围为-2的13次方到2的15次方减1,即-32768~32767常见这样的程序段: int num; num=89101; printf(“%d”,num); 得到的却是23565,原因是89101已超过32767。2个字节容纳不下89101,则将高位截去,即将超过低16位的数截去,也即89101-65536=23565,有时还会出现负数。这种情况应改为: Long int num; num=89101; printf(“%ld”,num); 注意,如果只定义num为long型,而在输出时扔用%d说明符,也会出现以上错误。 (4)在输出语句scanf中忘记使用变量的地址符。例如: scanf(“%d%d”,a,b); 这是很多初学者刚学C语言时常见的疏忽,应写为scanf(“%d%d”,&a,&b); (5)输入数据的形式与要求不符。例如有以下scanf函数: scanf(“%d%d”,&a,&b); 有人输入 3 , 4 ,这是错的数据间应该用空格来分隔,读者可以用printf(“%d%d”,a,b);来验证下。应该输入 3 4,除非函数是scanf(“%d,%d”,&a,&b); 还应注意不能企图用

C语言调试功能以及常见错误提示详解

C语言编译环境中的 调试功能及常见错误提示 调试功能 1.常用健 : 激活系统菜单 : 将光标在编辑窗口和、信息窗口之间切换 : 加载一个文件 + : 查看程序运行结果 : 得到有关编辑器在线帮助 + : 得到有关C语言的在线帮助 + : 终止正在运行的程序 2.块操作 KB: 定义块首 KK: 定义块尾 KV: 块移动 KC: 块复制 KY: 块删除 KH: 取消块定义 3.查找、替换和删除操作 QF: 查找字符串 QA: 查找并替换字符串 Option: G(全程),B(向文件头),N(直接替换) Y : 删除一行 QY: 删除从光标位置到行末的所有字符 编译中的常见错误例析 (1) 警告类错误 …XXX?declare but never used变量XXX已定义但从未用过。 …XXX?is assigned a value which is never used变量XXX已赋值但从未用过。 Code has no effect 程序中含有没有实际作用的代码。 Non-portable pointer conversion不适当的指针转换,可能是在应该 使用指针的地方用了一个非0的数 值。 Possible use of …XXX?before definition表达式中使用了未赋值的变量 Redeclaration of …main?一个程序文件中主函数main不止一个。 Suspicious pointer conversion可疑的指针转换。通常是使用了基本类型不匹配的指针。 Unreachable code程序含有不能执行到的代码。 (2) 错误或致命错误 Compound statement missing } in function main程序结尾缺少括号}。

调试与错误处理

第9章调试与错误处理 一、问答题 1.请思考如何避免错误。 答:1)事先精心设计应用程序,描述清楚相关事件以及代码响应每一事件的方法,为每一事件过程和每个普通过程都指定一个特点的、明确的目标。 2)多加注释。如果用注释说明每个过程的目的,在以后分析代码时,能更深入地理解这些代码。 3)对过程中用到的每个变量或对象都应该在过程开始部分加以定义。 4)在应用程序中对变量和对象提出一种前后一致的命名方案。 2.请简要设计错误处理程序的三个步骤。 答:1)捕获错误,并强制程序跳转 2)编写错误处理程序 3)退出错误处理程序 3.简述常用的程序调试技巧。 答:1)事先做好备份; 2)分离受怀疑的程序; 3)缩小搜索范围; 4)使用MsgBox语句。 4.简要说明VB程序调试的主要方法和工具。 答:VB 程序调试的主要方法:用编译器提示错误;使用调试工具来发现和改正错误;采用常用的调试技巧,如事先做好备份,分离受怀疑的程序,缩小搜索范围,使用MsgBox语句等。 主要工具:“调试”菜单下的“逐语句”、“逐过程”、“跳出”、“运行到光标处”、“添加监视”、“快速监视”、“切换断点”等子菜单项。 5.VB程序错误大体可分为哪几种,它们的含义是什么? 答:VB程序错误大体分为三种:编译错误、实时错误和语法错误。 编译错误是在编写程序时书写了有错误的语法的代码,导致VB编译器无法正确解释源代码而产生的错误,也称语法错误。实时错误是指在运行期间,一跳语句试图执行一条不可能执行的操作而产生的错误,也称运行时错误。逻辑错误是指程序的运行结果和程序员的设想有出入时产生的错误。 6.请说明On Error GoTo 与On Error Resume Next 的区别。 答:On Error GoTo 行标识符语句:当发生错误时,使用该语句强制改变程序的执行方向。而On Error Resume Next 语句:当发生错误时,VB程序将忽略引发错误的语句,并继续执行下一条语句。 二、程序设计题 1.程序改错。以前面学到的冒泡排序算法为例,开发以下程序,请上机练习排除其中的错误。 1

java异常处理试题及参考答案

异常处理练习题 一、选择题 1.java中用来抛出异常的关键字是(C) A、try B、catch C、throw D、finally 2.关于异常,下列说法正确的是(A) A、异常是一种对象 B、一旦程序运行,异常将被创建 C、为了保证程序运行速度,要尽量避免异常控制 D、以上说法都丌对 3.(A)类是所有异常类的父类。 A、Throwable B、Error C、Exception D、AWTError 4.java A、try{ C、 5. { { “除0 } A、程序将输出第15行的异常信息 B、程序第10行出错 C、程序将输出“b=42” D、程序将输出第15和19行的异常信息 6.下列程序的执行,说法正确的是(D) class ExMulti { static void procedure() { try

{ int c[]={1}; c[42]=99; } catch(ArrayIndexOutOfBoundsException e) { “数组超越界限异常:”+e); } } public static void main(String args[]) { try “除0 } A B C D 7. { { } { try { procedure(); } catch(IllegalAccessExcepton e) ___________ { “捕获:”+e); } } 8.对于catch子句的排列,下列哪种是正确的(B )

A、父类在先,子类在后 B、子类在先,父类在后 C、有继承关系的异常不能在同一个try程序段内 D、先有子类,其他如何排列都无关 9.在异常处理中,如释放资源、关闭文件、关闭数据库等由(C )来完成。 A、try子句 B、catch子句 C、finally子句 D、throw子句 10.当方法遇到异常又不知如何处理时,下列哪种说法是正确的(C ) A、捕获异常 B、抛出异常 C、声明异常 D、嵌套异常 11.哪个关键字可以抛出异常?(C) A、transient B、finally C、throw D、static JVM. int i=0; String greetings[]= { “Hello world!”, “No,I mean it!”, “HELLO WORLD!!” }; while(i<4) { ____try________ { }

STM 调试过程中常见的问题及解决方法

一、在“Debug选项卡”下设置好仿真器的类型后,下载程序时却提示“No ULINK Device foun d.” 解决办法:Keil MDK默认使用ULINK仿真器下载程序,在“Utilities选项卡”下把编程所使用的仿真器改为相应的类型即可。 二、编译工程时提示如下信息: main.axf: Error: L6218E: Undefined symbol __BASEPRICONFIG (referred from stm32f10 x_nvic.o). main.axf: Error: L6218E: Undefined symbol __GetBASEPRI (referred from stm32f10x_nvi c.o). main.axf: Error: L6218E: Undefined symbol __RESETFAULTMASK (referred from stm32f 10x_nvic.o). main.axf: Error: L6218E: Undefined symbol __RESETPRIMASK (referred from stm32f10x _nvic.o). main.axf: Error: L6218E: Undefined symbol __SETFAULTMASK (referred from stm32f10x _nvic.o). main.axf: Error: L6218E: Undefined symbol __SETPRIMASK (referred from stm32f10x_n vic.o). 解决办法:工程缺少“cortexm3_macro.s”文件,把cortexm3_macro.s和STM3210x.s全部添加到工程即可。 三、调试器不能连接到STM32的问题与解决办法 很多人都碰到过调试器不能连接到STM32的问题,不管是IAR的J-Link还是Keil的ULink,或者是ST的ST-Link。出现这个问题时,调试软件会提示不能建立与Cortex-M3的连接,或提示不能下载程序,或提示找不到要调试的设备等。 这样的问题都是发生在调试那些可以在CPU不干预的时候自动运行的模块、或在调试低功耗模式的程序的时候。所谓“可以在CPU不干预的时候自动运行的模块”包括:DMA、定时器、连续转换模式下的ADC、看门狗等模块。 -------------------------------------------------------------------------------- 这个问题的根源是: 1. 调试器需要在RAM内执行一段程序,对Flash进行擦写操作,如果不停止这些自动运行的模块,它们会干扰程序在RAM中的执行,致使下载失败。比如DMA模块被配置为不停地拷贝一段数据区,而调试器刚好需要使用DMA数据传输的目标区域,这时DMA的操作将会与调试器的操作发生冲突。再比如,如果启动了看门狗而没有执行硬件复位,则在下次调试器需要下载程序时,看门狗超时将触发芯片复位,导致下载操作失败。 2. 低功耗是通过停止CPU的时钟而实现,JTAG调试是通过与CPU的通信实现,停止了C PU的时钟致使调试器会失去与CPU的通信。 --------------------------------------------------------------------------------

相关主题