异常信息处理(精选10篇)
异常信息处理 篇1
0引言
母线电量平衡计算是用电信息采集系统应用的重要组成部分,作为最基础的数据,母线电量不平衡将严重影响用电信息采集系统中线路线损计算后续功能的应用。根据能源部颁布的《电力网电能损耗管理规定》,发电企业和供电企业的220 k V及以上变电站母线电量不平衡率不应超过±1%,220 k V以下变电站母线电量不平衡率不应超过±2%。理论上在建立好母线模型后,不会出现母线电量不平衡的现象,但在实际应用中该问题却经常出现。现根据多年采集现场运行维护经验,对常见母线电量不平衡问题进行归纳和分析研究,并总结出相应解决办法。
1电网实际运行工况发生变化,采集系统相关模型和参数与实际不符
(1)电网运行方式和潮流发生变化,导致原有母线电量不平衡。
例如35 k V寨科变,系统中母线电量平衡模型定义为:供入电量=3511炭寨线正向有功电量-3512官寨线正向有功电量-3501正向有功电量-3502正向有功电量。但在实际运行中,电网运行方式发生变化,35 k V寨科变由3512官寨线带负荷,3511炭寨线供入转供出,此时,供入、供出关系不对应,导致母线电量不平衡,应修改原有母线电量平衡模型。
(2)变电站更换计量装置倍率。
根据对变电站母线电量平衡报表的长期监测应用,如果出现母线电量不平衡,且不平衡率有规律地增加,应首先考虑核对模型中所有线路及主变电流互感器的倍率。
(3)新增间隔表计未添加。
由于负荷增长或变化,变电站出线间隔或发生变化,常见于新增出线间隔,新增出线间隔的电能计量表计未接入采集系统或系统中未维护添加对应的表计,会导致母线电量不平衡。例如:110 k V李寨变,35 k V主要带王洼煤矿负荷,近期由于新增负荷,35 k V母线新增两条出线,新增表计未添加到采集系统,导致母线电量不平衡。
2厂站电能量采集终端故障导致母线电量平衡问题的研判与处理
(1)在采集系统母线平衡常用报表“153母线电量平衡日报表”中,数据为空。
在此种情况下,应用局域网远程登录厂站电能量采集终端,查看终端所有进程,详见下述操作(以兰吉尔终端为例):
如缺少某项进程,应重新启动进程,则缺少必要的进程是导致终端运行不正常并导致母线报表为空的原因。如上述终端服务进程正常,则应应用服务软件,抄读终端时钟,如时钟与系统时间不对应,则应对终端进行远程对时和重启。在实际应用中,由于时钟不对造成的采集系统不冻结整点数据,从而出现母线电量为空的实例较常见。
(2)厂站电能量采集终端某一端口故障,该端口上所有连接表计采集失败,从而导致母线电量不平衡。
查看采集系统中1461母线日电量平衡明细,筛选出数据为空或者∞的计量点,在终端配置参数中核对是否属于同一端口,如属于同一端口,则可以确认为该端口故障。此类故障需到现场重新更换通讯端口,匹配参数。
(3)兰吉尔壁挂式终端内存溢出,停止采集,导致母线电量相关计算为空。
在固原公司早期进行厂站电能量采集建设时,使用了部分兰吉尔FFC系列壁挂式终端,这种壁挂式终端在当时具有体积小,只有普通三相高压表大小,安装方便的优点,且上行通信具备GPRS功能,在早期不具备光纤通信的条件下对实现厂站100%采集的目标功不可没。但由于它内存较小,通常只有1 G容量,加上变电站终端采集数据项及频次较大(每5 min采集一次),运行一段时间后容易出现数据溢出现象,从而导致出现停止采集的故障。最彻底的解决办法是更换新的终端。
(4)采集系统母线电量日平衡报表数据时有时无。
出现此类问题的一般原因有两个,一是RS485总线受干扰所致,解决方法如下:对于通讯电缆长度小于10 m,无强电和高压及高频干扰时,可以不使用屏蔽电缆,否则应使用屏蔽电缆,通讯电缆敷设应远离干扰源且屏蔽线二端必须接地;通讯电缆长度10~200 m,应使用屏蔽电缆,电缆敷设必须远离干扰源,且屏蔽线二端必须接地;通讯电缆长度200~250 m,建议最好使用光纤通讯方式,如果有困难,可以使用屏蔽线,但是电缆敷设时必须远离干扰源,在电缆沟中,通讯电缆与高频或高压的电缆应不在同一平面敷设,屏蔽线二端必须接地;通讯电缆长度大于250 m,必须使用光纤通讯方式;通常情况下,通讯电缆截面积不小于0.5 mm2;一根通讯电缆只能对应一个采集器接口,这样可防止串扰。二是一个串口接入的电表数量太多,在规定的间隔时间内无法完成采集。一般来说,5 min的时间间隔,一个通讯口所接电表数量不超过6只;15 min的时间间隔,一个通讯口所接电表数量不超过10只。
3母线报表中缺少部分计量点采集数据,且不属于同一通讯端口
此种情况多为关口电能表故障或电能表RS485通讯口故障、RS485通讯线接线错误。
3.1关口电能表故障
例如,35 k V孟塬变曾出现10 k V母线电量异常,经现场检查发现,114高庄线电能表异常,显示屏乱码,用万用表检查电能表RS485通讯口,如果A、B间的电压为5.7 V左右,高于正常电压,则判定为电能表故障导致总线上全部电能表通讯故障。
3.2 RS485接线问题
正常情况下国产电能表的RS485口电压为直流4 V左右,进口电能表为直流2 V左右。用万用表现场测量表计485AB电压为负(带负载),可判断485线接反;如果电压为零,可判断485接线短路或接地。通过从表计和终端解除RS485接线,使用万用表电阻档可以检测RS485的连接线是否短路或接地。在新建变电所厂站采集终端的安装调试中,还应用专用的通讯软件对各个总线上连接的电能表进行逐一召测。根据DL/T 645—2007《多功能电能表通信规约》的要求,终端超标工作在半双工模式,电表作为从动设备在接收到主设备的抄表请求后应在20~500 ms之间响应,以此来检查和核对每只电能表的通讯设置及RS485通讯线路连接是否正确,从而方便后续调试工作。
4结语
综上所述,本文基于用电信息采集系统对母线电量不平衡常见原因进行了分析,并提出了相应解决方案。此项工作需要熟练掌握用电信息采集系统的操作,具备一定的变电站关口电能计量采集现场维护经验,对出现异常的母线电量进行分析是一项长期的工作,需要不断地加强学习和积累经验。
摘要:随着用电信息采集系统建设的不断完善,采集系统的功能也越来越广泛,应用采集系统进行变电站母线电量平衡计算、线路线损计算、台区线损计算也已进入实用化阶段。作为最源头的数据,母线电量平衡是采集系统进行后续线路线损等相关计算的必备条件。现结合厂站终端的实际运行工况,对系统中母线电量平衡计算中出现的常见问题进行深入分析,以进一步明晰如何对系统中异常母线电量平衡进行分析及后续运维处理。
关键词:用电信息采集系统,母线电量平衡,异常,处理
参考文献
[1]张磊,王晓峰,李新家.电能信息采集系统运行及维护技术[M].北京:中国电力出版社,2010.
[2]张晶,郝为民,周昭茂.电力负荷管理系统技术及应用[M].北京:中国电力出版社,2009.
[3]虞忠年,陈星莺,刘昊.电力网电能损耗[M].北京:中国电力出版社,2004.
异常信息处理 篇2
品质异常处理流程
(公开文件,共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,负责对责任单位的改善结果进行追踪确认
/ 4 炳燊精密模具实业有限公司
异常责任单位:
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
/ 4 炳燊精密模具实业有限公司
如同一质量问题连续发起两次品质异常,验证结果无明显改善,则需采购部组织召开供应商评审,决定是否需要取消供应商资格。5.2
制程品质异常: 5.2.1 发现制程产品不良,应立刻停止加工。5.2.2 如异常属现场作业人发现,需立即找品质部确认不良现象可否接收。如异常可接受则继续生产,不可接收依5.2.3执行。5.2.3
依相关检验标准进行判定,确认不良成立时,应开具《检测不良记录表》。5.2.4 将不合格内容标识在工件上,立即移至不良品区域。5.2.4.1 不良品如以进行返工、返修达到合格要求,则由品质部发出《不良返修报告书》,生产对不良品进行返工、返修,返工返修后需交付品质进行检验,合格品进行出货区,品质回收报告书,统计返修用时,交返修者签名。5.2.4.2 判定重做时,生产1小时内填写补料单,交工程确认后,同《异常分析报告》一起交采购,采购1小时内下加急采购单,生产跟进材料,所有工序加急处理(如内部制程超出负荷,可申请外协)。如影响出货交期,营业客户客户交期。5.2.5 当异常问题严重,品质部又不能明确判定时,则由品质、工程、生产、营业共同会签,品质部开立《品质异常联络单》,责任部门分析原因、改善措施后,发送至营业部,最终由营业转发给客户,营业部负责跟踪客户回复处理结果,并将客户处理结果发给各部门。5.2.6
生产部按客户处理意见返工或重做(必须要有补料单),营业部1小时内回复客户最终送货时间。当处理意见为让步接收时,品质部将工件转入出货区,并附上《品质异常联络单》和客户回复的处理意见,出货时此工件不贴合格标签。5.2.7 制程品质异常开立时机。5.2.7.1 制程异常属材料所致,需第一时间通知责任单位、品质前往确认,双方判定标准一致,确认异常成立,则开立《品质异常联络单》要求责任单位改善。5.2.7.2 产品制造过程中如发现产品不良时,品质应开出《检测不良记录表》待工程、品质、制造担当分析出原因找出责任单位后由责任单位进行对策,品质部监控对策实施有效性 5.2.7.3 当产品制造不良时,品质应立即召集工程、品质等单位对问题点进行分析,找出原因和对策,等问题点解决后,方可再生产。相关不合格品的控制见《不合格处理流程》。5.2.7.4 品质再现(品质异常重复发生)时,开立《检测不良记录表》,通知生产单位整改。5.2.8 所有制程中《检测不良记录表》需生产部、工程部进行会签,生产、工程接到品质异常 3 / 4 炳燊精密模具实业有限公司
信息后半小时内需针对异常现象提出临时对策。5.2.9 责任单位需于《品质异常联络单》或《检测不良记录表》要求期限前,针对异常现象提出长期改善方案。5.2.10
品质部对责任单位回复内容进行确认,针对改善措施不合格部分予以退件,要求责任单位重新回复。改善措施合格,则报告予以归档,由品质跟踪后续进料品质状况,依5.2.11执行。5.2.11 返工OK产品需重新送品质检验,重新检验合格转入出货区,检验不合格依《不合格处理流程》要求执行。5.2.12 针对异常改善后产品,品质加严检验,连续追踪3批无异常后予以结案,转正常检验。5.2.13 如异常发生后连续2个月无生产,则强制结案,后续生产依正常检验执行。5.3 出货品质异常: 5.3.1
客户投诉或抱怨,由营业将投诉或抱怨内容0.5小时内发给品质部,抄送到生产、工程。5.3.2 如客户退货返修,依5.2.4.1执行。5.3.2.1
如客户判定重做时,依5.2.4.2执行。5.3.3 品质部24小时内分析外流原因及预防措施,并回复给营业部,抄送到生产、工程。5.3.4 营业部1小时内将品质回复内容确认,并回复给客户。5.3.5 异常单回复后,由文员统一归档整理/追踪。5.3.6 改善对策执行后,品质部依对策内容进行追踪确认,连续1个月内无同样异常外流再发,则予以结案。5.3.7 追踪期内再发则重新开立《检测不良记录表》,依5.3.4-5.3.6执行。
变电设备事故及异常处理 篇3
摘要:电力设备的正常工作是电力系统稳定运行的基础,本文作者总结了平时工作常见的变电设备事故类型,分析了造成事故的原因和处理方法,对指导变电设备的实际运行具有重要的参考价值。
关键词:变电设备;事故处理;变压器;故障
当前,保证变电设备的安全稳定运行,对电力系统的安全和稳定具有重要意义。变电设备一旦发生故障,如不能及时消除,会酿成大面积停电,将给社会带来灾难性后果。因此,提高变电设备的安全系数,对变电设备发生的事故及异常进行合理的处理,是避免事故扩大的有效措施。本文作者根据自身实际工作经验,对变电设备事故及异常处理进行了分析与研究。
一、运行事故及异常处理原则
1.事故及异常处理的主要责任
变电设备事故及异常的处理,必须严格遵守相关的工作规程。在事故处理的过程中,运行人员必须坚持“安全第一,预防为主”的方针,认真贯彻落实安全生产责任的制度和履行岗位责任的制度,努力完成工作任务,尽职尽责,以确保变电设备的运行安全。运行人员对于变电设备安全的主要责任为:
(1)依据调度的相关指令正确地进行倒闸操作。
(2)当发生事故、障碍时,按规定及时进行处理和汇报。
(3)完成电气设备工作的安全措施,办理工作票的开工和完工手续,对设备进行完工验收。
(4)当运行方式改变、恶劣天气、设备存在严重缺陷和缺陷有发展时,认真做好事故的预想。
(5)按规定进行故障处理,认真做好各种记录和报表。
2.事故及异常处理的顺序
运行人员要首先根据相关计量表及继电保护装置的动作情况判断故障的范围和可能发生故障的变电设备;其次必须重点检查相关的变电设备是否有运行的异常情况及异常的动作情况,以进一步地准备分析事故的性质和范围,必要时可立即采用措施,隔离出现问题的变电设备,以避免事故的进一步扩大。在分析相关事故的同时,运行人员还必须将异常情况及事故报告给调度,如果是严重的威胁生命的事故,必须立即给予切除或停止相关设备的运行,如果自动保护装置失灵未动,应手动给予切除。未影响到系统正常运行的变电设备,应最大限度地保障其安全稳定运行。
3.事故及异常处理的注意事项
(1)保障变电站自身的用电。变电站的相关操作需要以变电站有电为基础,如果变电站没有蓄电池或者变电站的蓄电池不够好用,则将更加凸显站用电的重要性。如果失去站用电,则一定会使的事故处理起来更加的困难,在规定的时间内必须首先恢复站用坏相关的变电设备。
(2)避免故障的范围的进一步扩大。变电设备故障及异常情况处理时,非常重要的原则就是避免事故的范围进一步的扩大,最大限度地减少损失。如果因为运行人员故障时的紧张而进行错误的操作,则会带来巨大损失,甚至可能引发电力系统连锁的大停电事故。
(3)尽快处理变电设备事故。变电设备故障及异常情况造成的事故必须尽快地处理,因为这些小的事故是电力系统的薄弱环节,为确保电力系统的安全、稳定运行,必须尽快消除这些薄弱环节,避免发生巨大的灾难性的事故。
二、输电线路异常及故障处理
线路故障的原因很多,情况也比较复杂。如站内线路出现设备支撑绝缘、线路悬吊绝缘子闪络,大雾、大雪等天气原因造成沿面放电,树枝、动物引起对地、相间短路等瞬时性故障;设备缺陷、施工隐患、外物挂断线路、绝缘子破损等永久性故障,以及瞬时性故障发展为永久性故障,原因多样,运行时应根据具体情况进行分析。
1.线路故障跳闸的现象
(1)警铃响、喇叭短叫,跳闸断路器位置指示灯短时出现绿灯闪光,红灯熄灭后,最后恢复正常状态,对应电流表和有功功率、无功功率表摆动,继而恢复正常。
(2)保护盘故障线路保护及重合闸动作信号灯亮或继电器动作掉牌,并指示故障性质及故障相别的动作情况,微机保护则打印出详细的报告。
(3)现场检查断路器位置三相均在合闸位置。电,这样才能使事故的范围不至扩大,不至于因为严重的事故而损。
2.线路跳闸的处理
(1)复归音响,记录故障时间,检查光字信号、表计指示和保护动作情况,确认后复归信号。
(2)检查断路器实际位置及动作断路器电流互感器外侧的一次设备有无短路、接地等故障,检查跳闸断路器油色是否变黑,有无喷油现象等。
(3)现场检查断路器位置三相均在合闸位置。
三、断路器异常及故障处理
断路器是电力系统操作控制的主要设备,其控制回路与直流、备的控制、保护、监视等功能。
1.断路器辅助触点转换异常现象
断路器辅助触点转换异常现象主要有:
(1)合闸操作时,绿灯闪光,红灯不亮或红、绿灯指示均熄灭。
(2)分闸操作时,红灯闪光,绿灯不亮或红、绿指示灯均熄灭。与断路器相连的隔离开关辅助触点转换异常现象为警铃响,主控盘可能发出“电压回路断线”、“电压回路同时切换”或“电压互感器并列”光字牌。
2.断路器辅助触点转换异常处理
断路器辅助触点转换异常时,应及时汇报调度,将对应断路器停运,然后打开断路器机构箱,检查连杆是否脱钩、转轴是否卡涩、触点的压接弹簧等是否正常及辅助触点转换是否正常等,可用螺丝刀进行调整,若无法处理,通知检修处理。与断路器相连的隔离开关辅助触点转换异常时,根据规程要求,若出现“交流电压回路断线”现象,则应首先汇报调度停用相关保护,然后再进行处理。及时检查相应重动继电器的失、励磁状态,如果确认是隔离开关辅助触点转换异常时,可以将隔离开关机构箱或转换触点盒打开,用螺丝刀进行调整,若无法处理,应通知检修处理。
3.断路器偷跳的异常现象处理
断路器“偷跳”的异常现象发生时,应首先尝试着合上断路器,恢复电网的正常运行;如果是发生三相跳闸,则必须投入相关的同期装置以实现同期合闸。此外还需区别引起断路器偷跳故障的原保护、自动装置、断路器操动、中央信号等相互联系,实现对一次设因,快速地处理断路器偷跳的异常现象。
4.断路器异常处理注意事项
(1)運行人员在实际的工作中是非常难判断由各种相关因素导致的断路器“偷跳”事故的,为确保以后不再发生相关的事故,可先准确地记录下出现的现象,事后再对数据进行分析,且在记录中必须严格地分辨一次系统的故障与二次故障的区别。
(2)断路器在发生“偷跳”现象后是绝对不允许再对其进行合闸操作的。必须检查断路器的操作机构、保护装置、二次回路的缺陷,对于不能检查只能观察的情况,需记录信号和现象,以免查找过程中再次导致断路器误跳,并汇报调度,保持断路器运行。
(3)若断路器“偷跳”,无法判明故障原因,运行人员按调度要求做好断路器停电处理措施,由上级部门处理。
四、结束语
综上所述,变电设备作为电力系统中的部件,其安全性和稳定性对电力系统的可靠运行具有重要影响。保证变电设备的正常工作,合理、正确地处理变电设备的事故及异常情况,有助于保障电力系统的安全供电,为构建以特高压为骨干网络的智能电网奠定坚实的基础。
参考文献:
[1]廖自强,余正海.变电运行事故分析及处理[M].北京:中国电力出版社,2004.
论异常与异常处理机制 篇4
异常是指意外事件或小概率事件。所谓异常处理, 指的是对错误或者程序执行期发生的其他不正常事件的处理。异常处理包括对异常情况的定义及对异常处理的处理两部分。典型的异常包括:运行期错误, 如对数组的越界访问或者除零错误;对于解释性语言“异常”还可能包括静态错误, 如语法或类型定义错误;当然异常还包括各种不常出现的事件, 如输入错误和超时等。
2 常见异常定义方法
2.1 C语言
在没有提供异常处理机制的语言中, 必须使语言在异常出现之前就发现有异常, 就相当于是提前预测了错误的发生, 然后进行避免。下面给出一个C语言的简单例子:
在上面的例子中, 因为没有异常处理机制, 所以在计算之前先进行判断以预防错误的发生。当然也可以自己封装异常处理库, 主要通过setjmp和longjmp两个函数来模拟实现。setjmp函数可以实现非局部标号, 而longjmp实现程序内部的任意跳转 (与之类似的经常使用的goto只能实现函数内部的跳转) 。对于这两个函数的具体细节这里不做过多说明, 都是错误出现之后模拟跳转, 然后输出通知错误的信息。
2.2 Java语言
Java语言的异常定义
Java的异常处理机制已经十分完善, 可以直接抛出一些异常处理类, 比如:
NullPointerException:空指针异常
SQLException:数据库处理异常
IOException:输入输出处理异常
ArrayIndexOutOfBoundsException:数组
下标越界异常
也可以继承Exception类自己定义异常处理类, 比如:
在上例中就是通过继承了最基本的Exception类然后加以填充。
3 异常处理程序结构模式与控制转移模式
Java语言
Java把异常当作对象来处理, 并定义一个基类java.lang.Throwable作为所有异常的超类。在Java API中已经定义了许多异常类, 这些异常类分为两大类, 错误Error和异常Exception。Java异常体系结构呈树状, 其层次结构图如图-2所示:
Error是程序无法处理的错误, 比如OutOfMemoryError、ThreadDeath等。这些异常发生时, Java虚拟机 (JVM) 一般会选择线程终止。而Exception是程序本身可以处理的异常, 这种异常分两大类运行时异常和非运行时异常。程序中应当尽可能去处理这些异常。运行时异常都是RuntimeException类及其子类异常, 如NullPointerException、IndexOutOfBoundsException等, 这些异常是不检查异常, 程序中可以选择捕获处理, 也可以不处理。这些异常一般是由程序逻辑错误引起的, 程序应该从逻辑角度尽可能避免这类异常的发生。
而非运行时异常是RuntimeException以外的异常, 类型上都属于Exception类及其子类。从程序语法角度讲是必须进行处理的异常, 如果不处理, 程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常, 一般情况下不自定义检查异常。
Java中异常处理则是通过5个关键字try, catch, throw, throws, finally来管理。基本进程是监视执行try模块的内容, 在try模块检测到的异常会被抛出, 在catch中异常会被抓到并作相应处理。还有一部分系统生成的Java执行时自动抛出, 可以通过throws关键字在方法上声明该方法要抛出异常, 然后在内部通过throw抛出异常对象。finnally关键字会在方法执行return之前执行。典型结构如下:
Java建立异常的模式和C++是一模一样的, 也是通过在try模块执行相应的语句, 建立要抛出的异常对象, 然后对其进行实例化, 抛出异常就可以了。
上面结构中Trouble和Big_Trouble都是继承了Exception的类, 是之前自行定义好的。所以可以直接调用显示错误信息。有上面可以看到, 其实各语言处理异常的大致结构都是一样的。只是涉及到具体的语法, 以及可以使用的已有方法的便利程度还有语言的完善性会有差别。Java做为现在开发最经常使用的语言, 在异常处理上已经做得很好了。
4 异常规范说明及典型示例
异常规范指的是函数说明部分的附加异常列表, 以确保该函数只抛出表中列出的异常。
举个例子说明Java的异常处理机制和控制方式:
这个程序的输出结果如下:
下面来分析一下这个程序:
先说明一下printStackTrace函数的作用是:在命令行打印异常信息在程序中出错的位置及原因。它是Exception类中定义好的方法。这个程序在主函数里是执行了testEx () , 然后一步一步走相当于是依次执行了testEx1 () 与testEx2 () 。但是值得注意的是testEx1 () 和testEx2 () 都没有执行完成, 因为在testEx2 () 中执行循环语句的时候会因为被除数i=0而导致出错, 于是抛出错误, 所以testEx2 () 的catch能够抓住错误, 并输出testEx2, catch exception.然后执行最后的finally模块中的语句, 输出textEx2, finally;return value=false.然而在返回继续执行testEx1 () 的时候由于textEx2 () 出错, 所以不会继续执行, 直接执行finally中的语句, 所以输出textEx1, finally;return value=false.同理在返回testEx () 执行的时候也是直接执行finally中的语句, 所以输出是上面的结果。
这个程序很好的展现了在Java中出现异常之后控制是如何转移的, 同时了解了关于异常基本的定义方法与抛出异常的方法。
异常处理是一个十分重要的过程, 它可以很好的避免一些悲剧事情的发生。也能够提供程序更好的安全性。我们应该在编写代码的时候注意细节。尽量避免错误的发生, 同时用异常处理机制进行保障。
参考文献
[1]Kenneth C.Louden.Programming Languages----Principles and Practice, second Edition.电子工业出版社。 (2004.4)
[2]郑莉.《Java语言程序设计 (第2版) 》.清华大学出版社 (。2011.1)
[3]李钟蔚.《Java从入门到精通 (第2版) 》.清华大学出版社 (。2010.7)
生产异常处理流程1 篇5
3.1 生产管理人员:负责提出异常,并确认异常是否属实,协助相关人员处理异常;
3.2 工程部:负责生产线上异常分析,找出异常原因,提出改善对策。3.3 品质部:负责跟进改善结果及效果确认,对来料进行管控,并对此类异常制定纠正预防措施。
3.4 总经办:负责生产过程中重大异常的方案决策、处理稽核。3.5 采购部:负责来料异常商务方面的异常处理。
3.6 计划部:负责异常发生时的总体计划的协调和异常发生产生的工时和物料的核实,组织相关部门一起分析、处理异常。异常处理作业流程:
4.1生产部按生产排期表提前到仓库领料并安排做首件并量产。
4.2生产部在生产中发现产品、物料与样品不符,生产出的成品达不到标准要求或来料无法使用等现象时,及时上报生产领班、品质部等相关人员确认。
4.3生产领班、品质部确认异常可接受,通知生产线继续生产,如确认异常不能接收则由生产领班或IPQC在异常发生的10分钟内开出《制程异常报告》,所有的《制程异常报告》由车间的IPQC拿到相关部门签字确认,最后由品质文员将单据发出,4.4经技术部分析,给出初步分析结果,结果分为工艺问题、设计问题、来料问题。
4.5由PE分析是来料问题、制程问题还是设计问题,并将分析的原因及解决方案记录在《制程异常报告》表上,并写给到工程部主管签名确认,如果需要返工或改变工艺则由工程部PE做出两块样品给到品质部确认,品质判定方案可行后,PE要在现场跟进生产部员工的作业方法、品质是否与样品一致。PE必须要等到生产员工做出2件合格品后方可离开现场,整个过程品质部要跟踪监控确认。
4.6如果确认是来料问题,《制程异常报告》采购部也要确认签字,并按照解决方案的意见与供应商沟通退货、换货、或由我司加工挑选扣除供应商相 应费用。并要求在一个工作日内对来料问题给予回复处理意见(临时解决办法),生产部要给予相应的配合和支持。同时品质检部应该协助采购部协商解决分析。
4.7如果由于异常原因造成的待工、返工工时,生产线应记录在当天的《生产日报表上》,计划部统一汇总。出现异常时生产线处理规则及注意事项
5.1.1当生产线不良超过20%,品质部要立即开出《停线报告》要求生产停线,《停线报告》同时要给到计划部一份,以便于计划部调整计划。不良率超过10%则由生产或品质开出《制程异常单》,处理方法同4.1-4.7项。低于不良品率低于标准时,由生产、品质管理人员协商解决。
5.1.2生产现场异常发生时必须由PE或生产管理人员及时确认,并马上反馈给相关人员给予指示,如果生产管理人员将异常反馈给相关人员后在1小时内没给出指示,生产有权停线、待工。
5.1.3生产线异常发生时,PE须在2小时内给出短期解决措施,如需要更改工艺或做工装、夹具的须在4个小时内给出解决措施,如果出现重大异常,PE不能很完善的解决问题,由PE反馈给工程部经理,由工程部经理通知计划部,再由计划部组织相关部门开会商讨解决。
5.1.4 PE分析异常原因必须要正确,专业,给出的解决方案必须要具有可操作性,还要能通过相关部门签字同意方可有效。如果有一个部门不同意观点,PE需要重新分析。最终结果要达到相关部门都没有意见的效果。
5.1.5 PE给出解决方案前要自行或找生产协助PE先做两个样品确认方案是否可行,并将样品交给相关部门确认。相关部门同意后,生产部就按照样品作业,生产在作业时PE要现场跟进前两个产品的作业方法是否与样品一致,确认无误后方可离开现场。
5.1.6出现异常后如果需要更改工艺或返工,生产、品质有权要求PE作出指导文件,PE要在4个小时内做出简易的作业指导书或返工流程给相关部门确认,生产按照PE的指导文件作业,品质部现场跟进、监督生产作业。5.1.7当出现异常时各个部门对解决方案有意见的时候,工程部要知会计划部,由计划部召集相关部门开会商讨,意见统一后由计划部分配各部门的工作任务,相关部门必须配合完成。执行过程中有任何问题要及时向计划部提出,由计划部协调处理。如果该异常各个部门无法达到统一意见,计划部有权将该异常交给某个部门或某个人主导负责,其它相关部门必须服从听取他的安排,配合执行各项任务。执行过程中有任何问题要及时向主导部门负责人汇报。主导部门负责人要及时给予解决。5.1.8以上整个过程品质部要监督跟进,有任何问题要及时汇报。5.2异常物料的处理
5.2.1经品质部或PE判断归属物料不良的由生产部在在一个工作日内开退料单到仓库进行退换料。
5.2.2由于设计或工艺造成的物料不良,按照《制程异常报告单》签核的物料损耗评估进行退换料。5.制程异常报告要求
5.1报告内容:型号、单号、工序,时间、异常描述。
5.2异常描述要求:要描述详细的不良现象、总生产数量、不良数量、不良比率、不良确认人、有条件最后。
5.3原因分析及确认:PE提供的原因分析必须是准确、客观、详细的。5.4改善措施:PE决策的解决方案必须要经过生产部、品质部、计划部的认同,相关部门负责人要签字确认,PE可提出临时的改善措施,以保证生产,若商讨结果需要生产部门协助挑选,计划部要在异常单上批注清楚,明确工时费用及物料损耗。6.设备异常处理流程
6.1设备出现异常,整个过程由设备工程师主导跟进处理,如在能力范围内不能解决的汇报给工程部经理主导解决,所有处理过程参照设备异常处理流程图。其它事项参照异常处理规则及注意事项
7、附件
7.1《制程异常报告单》
8、流程图
发现异常10分钟内IPQC/生产领班开出异常单5分钟内PE分析异常原因,及异常解决方案30分钟内来料不良设计不良制程不良NG品质负责人确工程/研发负责人确认OK由品质主导并跟进异常处理过程认OKNG生产负责人确认OK由PE指导生产执行解决生产部按照异常解决方案处理异常,并记录返工、待工工时计划部汇总异常工时品质部跟时处理结果是否可行NGOK要求责任部门给予出长期纠正预防措施,并监督实施结果验证NG结案
OK4
浅析Java异常处理机制 篇6
1 什么是Java异常和异常处理
异常是指程序运行过程中出现的中断正常的程序控制流的事件。没有异常处理代码的程序可能会非正常地结束, 引起严重问题。
异常处理是处理程序运行时出现的任何意外或异常情况的方法。异常处理使用try、catch和finally关键字来尝试可能未成功的操。异常处理分离了接收和处理错误代码, 这个功能理清了编程者的思绪, 也帮助代码增强了可读性, 方便了维护者的阅读和理解。
异常处理通常是防止未知错误产生所采取的处理措施。异常处理的好处是你不用再绞尽脑汁去考虑各种错误, 这为处理某一类错误提供了一个很有效的方法, 使编程效率大大提高。
2 必检异常和免检异常的区别
在整个的Java异常处理类的层次中如图1所示, 可以分为两大类异常:必检异常和免检异常。免检异常又称运行时异常, 它们是RuntimeException、Error以及它们的子类, 意思是指编译器不检查处理它们, 程序员可以不处理它们, 当出现这样的异常时, 总是由虚拟机接管。出现运行时异常后, 系统会把异常一直往上层抛, 一直遇到处理代码, 如果该异常没有被处理, 程序将终止。必检异常又称非运行时异常, 意思是指编译器会强制程序员检查并处理它们。
大多数情况下, 免检异常反映程序设计中不可重获的逻辑错误, 这些都是程序中必须纠正的逻辑错误。免检异常可能在程序任何地方出现。
3 异常的处理方法
Java语言为程序员提供了处理异常的方法。利用这种称为异常处理的方法, 能够开发出健壮的程序。表1中有两个例子, 例1中没有对可能的异常进行处理, 如果输入的不是整数, 程序将会非正常终止。例2中采用Java语言提供的try…catch…语句对可能出现的问题进行捕获处理, 当类错误发生时, catch语句块捕获它并且可以进行某些特定的操作, 包括是否终止程序。可以使用trycatch结构块处理这个错误, 它可以使程序捕获错误并继续执行。使得程序的相应更加优雅。
4 异常处理模型
Java的异常处理模型基于三种操作:声明异常、抛出异常、捕获异常。如图2所示。
5 结束语
异常处理机制使得程序无需在很多可能出错的地方增加冗长乏味的判断语句, 能够集中地处理程序错误或者异常情况, 提供了一种机制使得程序可以尝试从异常情况中恢复, 而不是完全崩溃。所以程序开发者应该合理的使用异常处理开发功能健壮的程序。
参考文献
[1]埃克尔.Java编程思想[M].陈昊鹏, 译.北京:机械工业出版社, 2007.
[2]昊斯特曼.Java核心技术[M].叶乃文, 邝劲筠, 杜永萍, 译.北京:机械工业出版社, 2008.
斜槽异常堵塞的分析及处理 篇7
检查斜槽内无异物, 充气箱内无积料, 斜槽风机电动机无反转, 斜槽风机出风管道阀门开度正常, 透气层透气性能良好。
05分格轮是密封式的, 将分格轮后端盖打开, 发现分格轮转速偏快。
综合上述情况分析认为:
1) 05旋风筒易塌料。由于分格轮与旋风筒连接密封条破损, 在拆除更换时, 发现旋风筒收集的料会间隔喷出, 由此判断入分格轮的料量忽大忽小。
2) 05分格轮减速机速比与原先不一致, 用秒表测05分格轮50r/min, 04分格轮25r/min。以前曾对05分格轮做过更换, 当时考虑05分格轮密封性能好, 粉尘不会从前后端盖溢出, 故更换时没有对照原减速机速比, 致使新的05分格轮能力偏大。这样, 在旋风筒不塌料的情况下, 斜槽尚能运行正常;但在05旋风筒出现塌料和分格轮转速偏快的双重影响下, 05分格轮的下料量瞬时变大, 造成04旋风筒收集下来的料无法顺利通过, 斜槽堵塞。
解决措施:
网间异常话务分析及处理 篇8
通过对网间业务的观察分析, 发现各种不规范的呼叫或者网间的违规行为频繁发生, 不仅增加了网络的负担而且也使公司效益受到影响, 针对这些情况我们充分利用现有的NO.7信令监测系统、OSE (实时业务分析系统) 、亿阳交换网管系统来监测分析电信网络的话务的异常情况。不断加强监测频次及转换监控手段, 全面地掌握网间异常话务的判断及分析, 采取有效措施, 以减少电信行为的非法现象的发生。
(1) 异常话务定义。“异常话务定义”是指不同于通常情况下发生的常规话务, 主要包括突发性话务、非法语音呼叫、假主叫、不规范主叫、主被叫号码相同 (指异常转移呼叫) 、异常信令及超长超频、超长超频呼叫等。
(2) 异常话务分类。按影响范围分:国际异常话务、省际异常话务、网间异常话务和本地网异常话务 (包括来话、去话) 。
以下主要针对网间异常话务呼叫进行分析及处理情况。
1、网间异常呼叫监控范围。
我们需重点关注两方面的情况, 一是存在网间套费风险的呼叫, 比如至本地过往长途。二是关注采取非法手段造成长途话务量流失的情况, 如通过VOIP或回拔平台系统进行长途分流的情况。不论哪种都给企业造成很大的经济损失, 所以我们要密切关注此类问题。
2、异常监测分析及处理。
2007年年初近半年多时间里, 通过亿阳交换网管系统对话务的观察、七号信令监测系统的查询以及OSE时实业务分析系统的辅助查询等发现, 各种异常呼叫频繁发生, 最具有代表性的网间异常现象有:
(1) 本地本网异常话务。
(1) 异常话务现象描述。2007年1月17日-2月14日期间。根据亿阳的交换网管系统话务分析时发现, 松原市—扶余县方向的话务量猛增, 同时上报给上级领导, 这是一起典型的发生在本地的网内的异常话务呼叫。2007年2月12日集团通报此事后, 省网管中心与松原分公司也进行了沟通, 得知在松原的扶余县曾出租8个2M的中继电路, 经七号信令系统监测发现猛增的话务就是从出租的电路呼出的, 经进一步调查、确认后, 最后对用户的行为进行了规范。
(2) 异常话务分析。其实在12日之前, 通过话务分析时发现其话务量猛增, 同时向上级领导汇报了此事。
表1是话务分析时的数据对比表。
同时进行七号信令监控系统对话务跟踪分析, 扶余零母局以02147483647为主叫号海量呼叫长途, 以及0438-5903000到0438-5903059计60个连号的假主叫海量呼叫长途, 造成话务量猛增。
(3) 处理方案。经了解得知这60个号, 都是从我网通出租给用户的中继电路过来的号码, 对用户的行为进行了规范, 结果取消此部分电路的出租, 从而遏制了此类事件的再次发生。
(2) 网间超长异常话务现象描述。
(1) 异常话务现象描述。2007年6月11日到月末将近一个月的时间, 在查询网间话务时发现, 主叫号为河南省许昌的0374*的固定电话呼叫我松原本地铁通的号码699*, 期间断断续续的话务量较高, 甚至最高的一小时将近200ERL居高不下;正常忙时的话务量才30Erl/小时左右, 凌晨2、3点钟几乎接近于零。
(2) 异常话务分析。
表2为5、6月份本地铁通的话务情况:在这将近一个月来的时间里, 尤其中旬至下旬的时间里, 有一主叫号为河南省许昌的0374*的固定电话呼叫我松原本地铁通的号码为69940*, 当我们反拨0374*的号时发现此号是空号, 拨被叫时是忙音, 用七号信令监控系统做进一步查询时发现, 此次假主叫呼叫的特点都是超长呼叫, 有的呼叫时间长达10-20个小时不等。
(3) 处理方案。把此种现象依次向相关的领导作汇报, 逐一的对被叫号码作封堵, 其作封堵后他会依次的改号, 然后我们再次一一作封堵, 形成了类似围追堵截的架势。
(3) 网间超频异常话务。
(1) 异常话务现象描述。8月3日下午至4日早6时, 话务有所增加, 经七号信令监测系统查询果然主叫0349-8184123呼叫它本地16871011后转接到我松原6994502和6994535两个号, 本次呼叫的特点为每次通话时间不长, 但次数较多, 数超频呼叫的异常话务, 一天总的话务量较其它正常时高100左右Erl的话务量。之后7日、8日这两天也有此种现象, 但是很少数的有通话的时长, 占用时长为几十秒。
(2) 异常话务分析。根据上述现象, 查询七号信令监测系统, 发现情况如表3:从8月3日00:00:11时开始-次日06:15:03时结束, 共发生此类呼叫19250条, 如能接通呼叫的, 通话时长大约为307秒左右, 总通话时长为856350秒, 合计:237.875小时。
(3) 异常话务产生原因。假主叫号为山西朔州网通的0349-8184123, 呼叫当地的被叫号为16871011后转到我松原本地的铁通的号码6994*, 从而大大的增加了我关口局——松原本地铁通的话务, 继而增加了网通-铁通间网间结算。
(4) 异常话务处理方案。经领导批准后, 在关口局上进行封堵, 每出现铁通这样的6994*的假号, 就针对此号做封堵。通过封堵, 是每次出现的异常呼叫消灭在萌芽当中, 从而减少了网间的异常话务, 让我们网通的损失降到最低。
3、预警分析
从上面的本地网内异常呼叫、网间超长异常呼叫和网间超频异常呼叫实例分析中看出, 对通信网内、网间各种情况进行严格规范, 虽然网间异常主叫一直是较难根除的问题, 有的运营商通过发送异常主叫来套取网间结算费用, 有的网络电话可以由主叫方任意设置主叫号码造成用户对电信运营商的信任危机, 还有其他等等一些复杂的情况, 但是我们可以充分利用No.7信令监测系统等监测工具, 对异常主叫进行预警分析, 从而作出相应处理。
实践证明, 各种不规范的呼叫或者网间的违规行为在信令流程上总会体现出某种规律, No.7信令监测系统提供了丰富的可供挖掘的数据源, 只要掌握了不规范的网间信令的规律, 就不难从中挖掘并提取出有价值的异常话务信息, 从而更早控制异常话务发生给公司造成的损失, 以便更好地服务于市场。
摘要:本文简要介绍了网间异常呼叫的监测方法, 主要叙述了网间异常呼叫现象的甄别及分析, 目的是及时发现并采取相应措施以减少话务流量的流失和套费的发生。
关键词:异常话务
参考文献
烟机振动异常的诊断与处理 篇9
新疆克拉玛依石化公司80万t/a催化装置主风机组, 由YL-4000D型烟机、MCL904-5型离心压缩机、YCH710-5型电机构成 (图1) 。烟机的作用是把催化裂化再生烟气中所具有的热能和压力能膨胀做功转变为机械能来驱动压缩机运行, 从而达到能量回收的目的。
烟机测点布置见图1, 外壳监测采用DP1500数据采集器、970i加速度传感器、Odyssey2.3分析软件, 系统构成为传感器—数据采集器—分析软件—计算机—输出设备;内部旋转轴监测采用西安交大的RotVIEW7.0系统, 硬件由笔记本计算机、多通道数据采集器、bently涡流传感器、PCM-3000系列A/D卡、并口线组成, 软件包括数据采集模块、临时在线监测模块、精密诊断模块。
2. 振动监测与诊断
(1) 外壳测点监测
2011年4月25日对机组进行定期振动监测时发现, 烟机1瓦、2瓦水平振动值与前期监测相比有所增大, 5月5日两个测点振动值均出现大幅度增加, 5月8日又进行了加测, 由表1可看出三个振动值超过一级报警值4.5mm/s。将5月5日采集到的数据传输回计算机, 借助Odyssey2.3分析软件进行分析, 从测点频谱图中可以看出, 烟机两支承瓦处的水平振动存在超标情况, 振动值上升较快, FFT频谱图转速频率均占绝对主导。
(2) 旋转轴测点监测
烟机1瓦径向的工频幅值与振动峰—峰值从3月24日起一直呈上升趋势 (表2) 。5月4日工频幅值增加较为明显, 轴心轨迹基本呈椭圆形。水平方向频谱图显示工频成分突出, 二维全息谱显示1×工频椭圆较明显, 其他成分较小。
5月4日对烟机2瓦监测显示, 轴心轨迹有突出的尖角 (图2) 。径向振动频谱图显示除工频成分外, 还存在倍频及分数倍频成分 (图3) 。
从上述监测情况可以看出, 烟机转子转子不平衡量有缓慢增加趋势, 存在较明显地工频故障, 并且还存在轻微动静摩擦及微不对中现象。
诊断结论:通过对内外部振动监测情况进行综合分析, 并结合该机组以往的运行及检修记录, 可以诊断此次振动异常主要是因为转子动叶片附着催化剂颗粒, 产生动不平衡所引起。
3.检查及处理
五月中旬车间启动备用机组后对烟机进行解体小修, 检查发现烟机机壳内部及动静叶片的工作面、背面都有一定数量的催化剂聚集物, 动叶片周向端面有比较明显的磨损痕迹, 可以确定是催化剂颗粒聚集造成叶片顶端与过渡环发生碰摩所致。烟机支承及止推轴瓦检查情况较好, 没有异常磨损情况。
将烟机动静叶片上的催化剂聚集物清除干净, 对整台机组重新对中。机组重新开机后跟踪监测显示, 烟机1瓦、2瓦外壳处水平方向振动值均降到1.5mm/s以下;旋转轴工频幅值及振动峰—峰值均比检修前有较大幅度下降, 检修后的烟机运行状况良好。
μm
摘要:催化烟气轮机动叶片周边附着了一定数量的催化剂粉尘颗粒, 导致烟机动叶片顶部受热胀效应与过渡环发生了碰摩, 造成烟机轴瓦振动在短期内出现较大幅度上升。采用状态监测诊断技术进行分析诊断, 经检修处理使烟机振动恢复正常。
试析Java语言异常处理技术 篇10
1 Java语言异常化处理的优势
Java语言对于程序中的异常问题的处理,往往首先在于对异常进行分类,借助不同结构和层次分类后能够对单项异常进行准确处理。异常处理实现了程序代码中出现错误段与正常段的分离,对于程序的可读执行性增强。错误在发掘后,会被传递到执行事件管理的调用堆栈中。异常处理技术能够主动捕获未发觉的错误并进行处理。这些技术优势确保异常处理的准确性大大提升。
Java语言的异常处理一般借助5个关键字“try、catch、throw、throws、finally”完成。基本思想为:先用try语句对存在疑问的局域进行监管,当try语句内有异常,则会及时被抛出,程序代码随着catch语句块的执行得以实现异常捕获并处理;通过throws语句方法声明并执行抛出,后在内部完成throw抛出异常;finally语句一般在return实现执行前处理,一般结构如下:
2 Java语言的异常分类
Java语言一般会根据特殊性的层次结构来进行对象化分类。首先看Java语言的类层次结构,异常类语言基本出自Throwable的子类,而可以按照逻辑错误Error类和Exception类来扩展Throwable子类分支。
在两类分支中,Error及其子类体系基本围绕程序运行错误及系统资源消耗殆尽等异常进行展示,语言编译单元不会直接检查整个Error及其子类体系。而Exception类又可以直接扩展为3类分支:运行时异常(Runtime Exception)、输入输出流异常(IO Exception)和用户自定义异常类,最后一类分支可以用图式**Exception表示。运行时异常(Runtime Exception)属于程序编写运行的错误,语言编译单元不会直接检查,因此与逻辑错误Error类一同可以称之为未被检测的异常。当出现未检测异常后,大多数依靠程序员的个人能力挖掘错误并及时修改。而输入输出流异常(IO Exception)和**Exception用户自定义异常类,则属于已经接受检查的异常。当程序员要对这些异常展开处理时,需使用“try-catch”来完成语句的捕获,当然也可以使用“throws”语句产生申明行为,完成异常部分的抛出,以便完成最后的编译工作。
通过上述的结构层次划分,可讲Java语言的异常分为用户自定义类或系统定义两种。用户自定义的异常一般就是由程序编译人员对程序的内在逻辑进行解读,根据需要创建特有异常对象,这些异常都与程序中的异常错误积极对应。在对自定义异常进行创建或抛出阶段,第一步应该使用Exception的子类创建方式定义异常类,并有效延续Exception类逻辑得以实现。Java语言是面向对象的语言,因此用户自定义的异常类与Exception类都有相同的面向对象相接的端口,也在这些端口中能够解析中定量的代码。通常,自定义用户异常的格式如下表示:
如下列代码段:
而由系统定义的异常类别,则可以包含在系统运行或程序数据处理过程中可自行预见的异常错误。系统条件中的类的定义同时也囊括了程序运行的错误信息,并附有合理的解决处理方案。如表1所示,可以将相应的系统自定义异常标识与异常缘由一一对应。
当然,无论是系统定义异常类还是用户自定义异常类,都不能单独成为描述系统全部异常状况的概括,同时也就无法准确地返回到用户需要了解和获知的详细信息。
3 Java语言的异常处理应坚持的原则
3.1定义异常位置的层次感
Java语言出现异常情况后需要处理,应先定义异常类,按照不同的类别将异常的实际反应与不同的目标对象进行对照例化。可以将定义Java语言的异常类当作是构建一棵大树的主要躯干部分,同时大树的每个部位可以对应在程序中出现的异常,这些树干部位都已经提前做好定义。当没有找到树干的定义异常部位后,就需要按照增添方面完成对新的异常树干位置的补充。异常分类的不同定义,因此具有了层次化的位置处理,在后期的程序代码维护中便于处理,同时其一一对应的关系能够帮助用户更快地通过异常找到导致的原因。
3.2声明异常的精准化原则
在对异常进行声明时坚持精准化原则,能够更快对应找准异常产生的缘由。例如,当输入输出流异常IO Exception类的体系运行时,往往在定义My Read方法中,需要声明其属于输入输出流异常IO Exception类,而不会因为IO Exception类属于Exception类的子类分支,将声明改为Exception类,具体的语句格式可见:
通过精准的声明定位,能够将语句后部分的抛出位置指定的更加具体。
3.3异常try语句块的简易原则
Java语言的异常处理中,常需要将各种异常可能性置于较大容量的try语句块中,这样整合的做法就是非常有利于程序的编写。不过也会导致很多的不利结果:try语句块容量加大后,相应的异常数也会增多,在海量数据中挖掘报错的原因无疑增加了难度。同时,大容量的运行容易导致系统在解读和运行程序时内存或CPU处理超负荷损毁的风险加剧,无疑为程序编码的运行效率产生不小的制约。
3.4避免异常遮掩
容纳语言异常的try语句块在接受处理并抛出后,如果同时伴随catch或finally语句块中出现已检查异常抛出,就有会部分异常因间隙的存在被遮掩。处于被遮掩状态的异常将无法及时传播,而最后阶段的外围异常则会传递到调用堆栈。这样的情况下,程序很可能在运行中因异常的遮掩累积而出错停止。而且,想要重新寻找异常的导致原因,还需要让异常不受遮掩,也就是避免在try语句块抛出后立即伴随catch或finally语句块抛出。
3.5异常段自动隔离
很多Java程序语言都存在可循环的执行语句。当执行语句在运行中持续循环后,一旦产生异常,那异常就会在这样的循环结构中反复执行,从而直接影响到其他程序语言,出现更多的异常。异常处理技术中常会采用中断跳转模式,即程序运行中出现异常会中断运行,并跳转到其他位置。如果在循环中大量出现异常段,只会让程序的运行频繁跳转,不仅增加运行消耗,使得程序的执行速度降低,而且特别容易出错,还无法有效查询到错误发生的原因,一般上如果不把异常段与循环结构体主动隔离,则主程序的报错很难实现有效恢复。
3.6异常事件的资源清理
在Java语言中,异常事件产生后会产生包括操作痕迹的资源,常用finally块来完成清理。finally块的使用应在开始资源释放前就得到更为准确的应用,要采用一对一的形式。若因两个以上资源同时定义一个finally块,则可能存在其他资源出现申请错误或释放错误,这样就不太利于第一资源的积极释放。异常事件处理中,必然要注意finally块与资源申请语句的对应呈现,才能让资源得到有效利用。
4常见两种异常处理方式
Java对于异常出现后的处理,往往将可识别的错误包装成对应的类对象,统一集中在对象程序段中实现处理。对于异常代码一般有两种处理办法:
4.1 try...catch语句
try...catch语句方法的使用,便于捕获并及时处理异常事件。catch语句可实现多个排列,以便保障不同异常的对应,例如:
4.2 throws语句
在Java语句中存在很多异常有时较为难处理,可以借助方法声明,由throws语句完成异常事件的抛出。例如:
当然,并不是所有的方法都只要简单抛出就行。若某方法可以简单抛出异常事件,则在用于方法调用的多层次嵌套结构中采用调用,Java虚拟机就能够主动在有异常状况出现的代码块中重复地读取扫描往返寻找,一直待异常代码块完成最终处理为止。异常快被找出后将由catch语句执行处理。
当然,如Java程序存在的系统要采用方法调用直接追溯到堆栈最底层后,调用main()方法寻找异常时,若尚且未找到异常处理码,就需要按照下列步骤完成处理:
(1)调用print Stack Trace()方法。这一方法可以将调用栈的出现异常的信息数据直接打印。
(2)若异常线程认定为主线程,程序运行就会直接受影响被终止;但如果认定为非主线程的异常,则单线程的终止不会影响其他线程的运行。
5结语
Java语言异常处理技术可以正确识别出错与正常的代码,并分离式处理,具有一定的优越性。在异常处理同时,要注意随着程序运算量的增加可能导致计算机的运行变慢。因此,对于广大编程人员而言,采用什么方法来完成异常处理应该需要慎重对待,要在异常处理工作中保持科学合理性。
参考文献
[1]夏宇.基于Java常见异常处理研究[J].计算机光盘软件与应用,2012,(8):182-183.
[2]夏先波.Java JDK实例宝典[M].北京:电子工业出版社,2008.
【异常信息处理】推荐阅读:
异常处理08-02
异常处理模型10-26
程序开发中异常的理解及处理异常论文10-20
Java异常处理分析10-19
工作流异常处理08-21
异常问题的处理方法11-23
品质异常处理流程精12-07
工作流异常处理技术06-04
生产异常处理管理办法06-18
SMT工艺异常处理流程08-21