异常信息的处理方法及装置
技术领域
本发明涉及计算机软件领域,具体而言,涉及一种异常信息的处理方法及装置。
背景技术
在应用程序(APP)的开发过程中,APP开发人员会使用到软件开发包(SDK),比如在开发IOS APP的时候,SDK的开发人员会提供IOS SDK给APP开发人员使用,从而完成IOS APP的开发。IOS APP在运行的过程中偶尔会意外崩溃即发生异常,那么就需要开发人员对上述异常问题进行分析和解决。
这里需要说明的是,在IOS APP出现异常时,无法区分上述崩溃是源于软件开发包(SDK)还是APP本身,现有技术要将异常信息同时发送给软件开发包(SDK)的开发人员和APP开发人员,而SDK的开发人员和APP开发人员需要同时对上述异常信息进行分析从而解决问题(尽管上述异常的发生可能与其中一方无关),导致了在解决异常问题时耗时长、APP开发人员和SDK开发人员容易对某些问题产生分歧、对异常信息的解决效率低的问题。
针对现有技术中IOS应用程序发生异常时,要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。
发明内容
本发明的主要目的在于提供一种异常信息的处理方法及装置,以解决现有技术中IOS应用程序发生异常时,要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。
为了实现上述目的,根据本发明实施例的一个方面,提供了一种异常信息的处理方法,该方法包括:采集应用程序运行过程中出现的异常信息,其中,应用程序运行于IOS系统,在应用程序的线程中注册有未处理异常的处理处理方法;通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块,其中,多个匹配处理模块预先定义对应的编程用户的异常模式信息;在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理。
为了实现上述目的,根据本发明实施例的另一方面,提供了一种异常信息的处理装置,该装置包括:采集模块,用于采集应用程序运行过程中出现的异常信息,其中,应用程序运行于IOS系统,在应用程序的线程中注册有未处理异常的处理处理方法;分发模块,用于通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块,其中,多个匹配处理模块预先定义对应的编程用户的异常模式信息;处理模块,用于在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理。
在本发明实施例中,采用采集应用程序运行过程中出现的异常信息,其中,应用程序运行于IOS系统,在应用程序的线程中注册有未处理异常的处理处理方法;通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块,其中,多个匹配处理模块预先定义对应的编程用户的异常模式信息;在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理,解决了现有技术中IOS应用程序发生异常时,要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。
附图说明
构成本申请的一部分的附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例一的一种异常信息的处理方法的流程图;以及
图2是根据本发明实施例二的一种异常信息的处理装置的示意图。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例一
本发明实施例提供了一种异常信息的处理方法。该方法包括步骤如下:
步骤S12,采集应用程序运行过程中出现的异常信息,其中,应用程序运行于IOS系统,在应用程序的线程中注册有未处理异常的处理处理方法。
这里需要说明的是,在一种优选的实施例中,本申请提供的方案可以适用于IOS操作系统中运行的应用程序。
具体的,在IOS操作系统中运行应用程序的过程中,可以注册未处理异常的处理方法。可以利用IOS API注册全局的未处理异常的处理方法,可选的,部分实现代码如下:
NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
具体的,在本方案中,线程在发生未捕获异常后会主动调用UncaughtExceptionHandler函数,这样就是实现了异常信息的采集工作。
步骤S14,通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块,其中,多个匹配处理模块预先定义对应的编程用户的异常模式信息。
具体的,在本方案中,可以通过上述全局未处理异常的处理方法来将上述异常信息同时分发至多个匹配处理模块,可选的,在上述多个匹配处理模块中预先定义异常模式信息具体为,每个编程用户可能发生何种异常,例如:在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常信息,在匹配处理模块B中预先定义的是编程用户02的原因导致的应用程序发生的异常信息。
在一种可选的实施例中,上述编程用户01为IOS SDK的开发人员,上述编程用户02为IOS APP的开发人员。
步骤S16,在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理。
具体的,在本方案中,在将上述异常信息发送至多个匹配处理模块时,可以将上述异常信息和上述多个匹配处理模块中的异常模式信息进行匹配,以上述编程用户01为IOS SDK的开发人员为例,如果,匹配处理模块A中的信息与上述异常信息相匹配的话,则说明,上述异常信息为IOS SDK的开发人员的原因导致的,在本方案中的一种可选的实施例中,可以将上述异常信息发送至编程用户01,即发送至IOS SDK的开发人员。
此处需要说明的是,在本方案中,不但可以初步区分异常原因是出自IOS SDK的开发人员或IOS APP的开发人员,在本方案提供的又一种可选的实施例中,在确定具体的异常类型后,例如异常的原因出自IOS SDK的开发团队后,还可以通过本申请提供的方案将异常信息进行进一步的判断,从而将异常信息发送至具体的某一个IOSSDK的开发人员。
基于上述对异常信息的处理方法,可以实现当应用程序发生异常时,通过本方案可以自动分辨该异常是由于哪个具体的编程用户的原因造成的,从而将上述异常信息发送给相关的软件开发人员,可以提高应用程序异常处理的效率,从而解决了现有技术中IOS应用程序发生异常时,要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。
可选的,步骤S14,通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块的步骤可以包括:
步骤S141,在未处理异常的处理方法中调用分发功能函数,通过分发功能函数将异常信息分发至多个匹配处理模块。
具体的,在本方案中,可以在未处理异常的处理方法中的uncaughtExption方法中调用主题类中的notify功能函数即notify方法,通过上述notify方法将异常信息分发至多个匹配处理模块。
可选的,实现上述功能的部分代码如下;
结合上述代码,在本方案中,可以调用上述UncaughtExceptionHandler方法内容中的Notify方法来实现上述异常信息的分发。
可选的,上述分发类在本方案中可以为全局异常主题类UncaughtExceptionSubjectImpl,上述全局异常主题类为IUncaughtExceptionSubject接口的具体实现类,上述IUncaughtExceptionSubject接口为全局异常的主题接口,在上述主题接口中定义了上述notify方法。
在一种可选的实施例中,可以采用观察者模式的方式完成异常信息的分发与处理,这里,观察者模式为软件设计模式之一,分为主题和观察者,观察者订阅主题,当主题发生变化时通知相应的观察者。具体的,首先,定义全局异常的主题接口IUncaughtExceptionSubject,在该主题接口定义有notify方法,而UncaughtExceptionSubjectImpl为对主题接口IUncaughtExceptionSubject的具体实现类即全局异常主题类。关于上述创建主题接口和主题类的部分代码如下:
IUncaughtExceptionSubject*uncaughtExceptionSubject=[[UncaughtExceptionSubjectImpl alloc]init];
然后,定义全局异常的处理接口IUncaughtExceptionobserver,即观察者接口,通过该接口,开发人员可以实现自己的全局异常处理,比如,检查当前的异常是否是自己的代码问题引起的。而IUncaughtExceptionobserverImpl为对接口的具体实现类即观察者类。关于上述创建观察者接口和观察者类的部分代码如下:
IUncaughtExceptionObserver*uncaughtExceptionObserver=[[UncaughtExceptionObserverImpl alloc]init];
这里需要说明的是,上述步骤S14中多个匹配处理模块的功能可以通过上述观察者接口和观察者类来实现,即当异常发生时,可以调用上述主题接口中的notify方法来将异常信息通知给相关观察者,相关观察者则负责对上述异常信息进行进一步的处理。
可选的,步骤S16中在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理的步骤包括:
S161,提取异常信息中的异常特征,其中,异常特征包括如下至少一个:异常类名称、异常函数名称。
可选的,上述异常类名称和异常函数名称可以分别为:ClassName=”Y”,Method=”Z”。
S162,将异常特征同多个匹配处理模块中的预先定义的异常模式信息进行匹配。
S163,在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下,将异常信息发送至第一匹配处理模块对应的编程用户进行处理。
具体的,由于在每个匹配处理模块中都分别预先存储了不同的异常模式信息,例如,在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常模式信息,匹配处理模块A中的异常模式信息也包括:异常类名称以及异常函数名称,观察者类接收通过主题接口发送的异常信息进行提取,提取出实际发生异常的异常参数,即异常类名称以及异常函数名称,将上述实际发送的异常参数同匹配处理模块中预先定义的异常参数即上述异常模式信息进行匹配,如果匹配成功的话,说明上述应用程序发生的异常即为编程用户01的问题所造成。
在一种可选的实施例中,上述匹配处理模块的提取、匹配功能可通过如下方式实现,即通过调用上述观察者类中的(bool)HandleUncaughtException:(NSException)exception方法中检测提取异常的相关信息,如:在异常的堆栈中提取异常包名称,异常类名称,异常函数名称,根据这些信息判断相关信息是否与当前观察者定义的模式匹配,如果匹配,相关观察者实现类将该信息发送给相应的编程用户。
这里需要说明的是,上述HandleUncaughtException方法的实现还可以通过相关SDK或者APP中定义的预设命名规则加以鉴别匹配,例如:SDK实现了预设的命名空间命名或者预设的类命名规则或者预设的函数命名规则。
可选的,上述分发记录包括多个匹配处理模块的地址,上述未处理异常处理类依照上述地址将异常信息分发至不同的匹配处理模块,即发送至不同的观察者类。
步骤S163,将异常信息发送至第一匹配处理模块对应的编程用户进行处理之后,本发明实施例可以提供如下两个方案:
方案一:
将任意一条新的匹配处理模块的地址增加至分发记录,形成新的分发记录,使得未处理异常的处理方法将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。
具体的,在一种可选的实施例中,在上述主题接口中还可以定义Add方法,通过调用该方法,一个IUncaughtExceptionObserver观察者可以实现对上述主题的订阅,即当异常信息发生时,调用主题类中的notify方法将异常信息发送至该观察者,所以在本方案中可以通过调用上述Add方法对上述分发记录中增加一条新的匹配处理模块的地址,上述新的匹配处理模块中预先定义有新的编程用户可能造成的异常的异常模式信息,当新的异常发生时,则本方案将异常信息同样发送至新的匹配处理模块,以便将异常信息发送至相应的编程用户。例如,在本方案的上述例子中,应用程序的开发人员主要分为IOS SDK开发人员和IOS APP的开发人员,当然一个应用程序可以由新的开发团队加入,当新的开发团队加入时,则可以调用上述Add方法增加一个新的匹配处理模块的地址。
方案二:
将分发记录任意一条匹配处理模块的地址移除,形成新的分发记录,使得未处理异常的处理方法将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。
具体的,在一种可选的实施例中,在上述主题接口中还可以定义Remove方法,通过调用该方法,一个IUncaughtExceptionObserver观察者可以实现对上述主题的退阅,即当异常信息发生时,则不将上述异常信息发送至该观察者,所以在本方案中可以通过调用上述Remove方法对上述分发记录中移除一条新的匹配处理模块的地址,当新的异常发生时,则本方案不将异常信息同样发送至该匹配处理模块。例如,在本方案的上述例子中,应用程序的开发人员主要分为IOS SDK开发人员和IOS APP的开发人员,如果提前确认上述IOS SDK的开发人员提供的开发包不可能使应用程序出现异常时,则可以调用上述Remove方法移除该IOS SDK对应的匹配处理模块的地址。
下面本方案结合具体应用场景详细描述:
首先,本发明技术方案的技术原理为首先实现一个异常处理与分发的接口,该接口实现设计模式中的主题方面的接口,观察者类实现观察者模式中观察者方面的接口,当异常发生时,主题类通知该观察者类,同时利用观察者模式实现了分发和处理的解耦,方便以后扩展。
其次,本发明技术方案的整体思路为首先利用IOS API注册全局的未处理异常的处理方法,然后在该方法中通过主题类分发异常信息,观察者类即异常处理的类实现异常的特征的提取与匹配,如匹配将相关信息发送到自己。
具体的,为实现上述功能,在本方案中创建了主题接口,主题类、观察者接口和观察者类,上述类和接口的具体解释如下:
主题接口:IUncaughtExceptionSubject,可以通过调用这个接口的Add或者Remove方法,一个IUncaughtExceptionObserver观察者接口可以实现对该主题的订阅和退阅,同时当异常发生时IUncaughtExceptionSubject接口通过调用Notify通知相关观察者。
在主题接口中定义了三个方法如下:
Add(IUncaughtExceptionObserver)observer:该接口方法接受一个IUncaughtExceptionSubject参数,表示全局异常处理接口这个接口的订阅。
Remove(IUncaughtExceptionObservr)observer;该接口方法接受一个IUncaughtExceptionSubject参数,表示全局异常处理接口这个接口的退阅。
Notify With(Throwable)exception:这个接口方法接受一个异常类参数,通过调用该方法将这个异常类通知到所有订阅全局异常主题的订阅者。
主题实现类UncaughtExceptionSubjectImpl:这是一个对上述IUncaughtExceptionSubject接口的具体实现类。
观察者接口:全局异常的处理接口,通过实现该接口,开发人员就可以实现自己的全局异常处理(例如,检查当前的异常是否是自己的代码引起的等)。
在上述观察者接口中定义了如下方法:(bool)HandleUncaughtException:(NSException)exception。
观察者实现类UncaughtExceptionObserverImpl:是一个对上述IUncaughtExceptionObserver接口的具体实现类。
可选的,结合部分代码描述本方案:
在IOS APP启动时调用如下方法:
其中UncaughtExceptionHandler是一个处理异常的全局方法定义如下:
UncaughtExceptionHandler方法如下:
通过以上方法,调用uncaughtExceptionSubject全局异常主题的Notify方法通知注册该主题的所有订阅者。
其中UncaughtExceptionObserverImpl是一个具体的全局异常的订阅者,实现思路如下:在(bool)HandleUncaughtException:(NSException)exception方法中检测提取异常的相关信息,如:在异常的堆栈中提取异常程序集名称,异常类名称,异常函数名称,根据这些信息判断相关信息是否与当前观察者定义的模式匹配,如果匹配相关观察者类实现者将该信息发送给自己。
本申请提供的方案的关键点在于,在全局的未捕获异常处理器中处理相关异常。通过观察者模式跟踪异常发生的相关情况。在观察者中提取相关特征并匹配。匹配成功则通知相关负责人。
综上,本申请提供的方案优点如下:
(1)因为本方案能把不同开发人员开发的代码的异常分发给相关开发人员,所以避免了大家一起对某个异常同时关注而造成的时间损耗,提高了效率。
(2)提高了SDK开发人员发现问题与解决问题的效率。
(3)提高了APP开发人员发现问题与解决问题的效率。
实施例二
本发明实施例还提供了一种异常信息的处理装置,如图2所示,该装置可以包括:
采集模块22,用于采集应用程序运行过程中出现的异常信息,其中,在应用程序的线程中注册有未处理异常的处理方法。
分发模块24,用于通过未处理异常的处理方法将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块,其中,多个匹配处理模块预先定义对应的编程用户的异常模式信息。
具体的,在分发模块24中,可以通过上述全局未处理异常的处理方法来将上述异常信息同时分发至多个匹配处理模块,可选的,在上述多个匹配处理模块中预先定义异常模式信息具体为,每个编程用户可能发生何种异常,例如:在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常信息,在匹配处理模块B中预先定义的是编程用户02的原因导致的应用程序发生的异常信息。
在一种可选的实施例中,上述编程用户01为IOS SDK的开发人员,上述编程用户02为IOS APP的开发人员。
处理模块26,用于在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下,将异常信息发送至异常信息对应的编程用户进行处理。
具体的,在处理模块26中,在将上述异常信息发送至多个匹配处理模块时,可以将上述异常信息和上述多个匹配处理模块中的异常模式信息进行匹配,以上述编程用户01为IOS SDK的开发人员为例,如果,匹配处理模块A中的信息与上述异常信息相匹配的话,则说明,上述异常信息为IOS SDK的开发人员的原因导致的,在本方案中的一种可选的实施例中,可以将上述异常信息发送至编程用户01,即发送至IOSSDK的开发人员。
此处需要说明的是,在处理模块26中,不但可以初步区分异常原因是出自IOSSDK的开发人员或IOS APP的开发人员,在本方案提供的又一种可选的实施例中,在确定具体的异常类型后,例如异常的原因出自IOS SDK的开发团队后,还可以通过本申请提供的方案将异常信息进行进一步的进行判断,从而将异常信息发送至具体的每一个IOS SDK的开发人员。
基于上述对异常信息的处理装置,可以实现当应用程序发生异常时,通过本方案可以自动分辨该异常是由于哪个具体的编程用户的原因造成的,从而将上述异常信息发送给相关的软件开发人员,可以提高应用程序异常处理的效率,从而解决了现有技术中IOS应用程序发生异常时,要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。
可选的,分发模块24还可以包括:
子分发模块241,用于在未处理异常的处理方法中调用分发功能函数,通过分发功能函数将异常信息分发至多个匹配处理模块。
具体的,在本方案中,可以在未处理异常的处理方法中的uncaughtExption方法中调用主题类中的notify功能函数即notify方法,通过上述notify方法将异常信息分发至多个匹配处理模块。
可选的,实现上述功能的部分代码如下;
结合上述代码,在分发子模块241中,可以调用上述UncaughtExceptionHandler方法内容中的Notify方法来实现上述异常信息的分发。
可选的,上述分发类在本方案中可以为全局异常主题类UncaughtExceptionSubjectImpl,上述全局异常主题类为IUncaughtExceptionSubject接口的具体实现类,上述IUncaughtExceptionSubject接口为全局异常的主题接口,在上述主题接口中定义了上述notify方法。
在一种可选的实施例中,可以采用观察者模式的方式完成异常信息的分发与处理,这里,观察者模式为软件设计模式之一,分为主题和观察者,观察者订阅主题,当主题发生变化时通知相应的观察者。具体的,首先,定义全局异常的主题接口IUncaughtExceptionSubject,在该主题接口定义有notify方法,而UncaughtExceptionSubjectImpl为对主题接口IUncaughtExceptionSubject的具体实现类即全局异常主题类。关于上述创建主题接口和主题类的部分代码如下:
IUncaughtExceptionSubject*uncaughtExceptionSubject=[[UncaughtExceptionSubjectImpl alloc]init];
然后,定义全局异常的处理接口IUncaughtExceptionobserver,即观察者接口,通过该接口,开发人员可以实现自己的全局异常处理,比如,检查当前的异常是否是自己的代码问题引起的。而IUncaughtExceptionobserverImpl为对接口的具体实现类即观察者类。关于上述创建观察者接口和观察者类的部分代码如下:
IUncaughtExceptionObserver*uncaughtExceptionObserver=[[UncaughtExceptionObserverImpl alloc]init];
这里需要说明的是,上述分发模块24中多个匹配处理模块的功能可以通过上述观察者接口和观察者类来实现,即当异常发生时,可以调用上述主题接口中的notify方法来将异常信息通知给相关观察者,相关观察者则负责对上述异常信息进行进一步的处理。
可选的,处理模块26还可以包括:
提取模块261,用于提取异常信息中的异常特征,其中,异常特征包括如下至少一个:异常类名称、异常函数名称。
可选的,上述异常类名称和异常函数名称可以分别为:ClassName=”Y”,Method=”Z”。
匹配模块262,用于将异常特征同多个匹配处理模块中的预先定义的异常模式信息进行匹配。
子处理模块263,用于在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下,将异常信息发送至第一匹配处理模块对应的编程用户进行处理。
具体的,由于在每个匹配处理模块中都分别预先存储了不同的异常模式信息,例如,在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常模式信息,匹配处理模块A中的异常模式信息也包括:异常类名称以及异常函数名称,观察者类接收通过主题接口发送的异常信息进行提取,提取出实际发生异常的异常参数,即异常类名称以及异常函数名称,将上述实际发送的异常参数同匹配处理模块中预先定义的异常参数即上述异常模式信息进行匹配,如果匹配成功的话,说明上述应用程序发生的异常即为编程用户01的问题所造成。
在一种可选的实施例中,上述匹配处理模块的提取、匹配功能可通过如下方式实现,即通过调用上述观察者类中的(bool)HandleUncaughtException:(NSException)exception方法中检测提取异常的相关信息,如:在异常的堆栈中提取异常包名称,异常类名称,异常函数名称,根据这些信息判断相关信息是否与当前观察者定义的模式匹配,如果匹配,相关观察者实现类将该信息发送给相应的编程用户。
这里需要说明的是,上述HandleUncaughtException方法的实现还可以通过相关SDK或者APP中定义的预设命名规则加以鉴别匹配,例如:SDK实现了预设的命名空间命名或者预设的类命名规则或者预设的函数命名规则。
可选的,上述分发记录包括多个匹配处理模块的地址,上述为处理异常异常处理类依照上述地址将异常信息分发至不同的匹配处理模块,即发送至不同的观察者类。
本发明实施例二提供的异常信息的处理装置还可以包括:
增加模块27,用于将任意一条新的匹配处理模块的地址增加至分发记录,形成新的分发记录,使得未处理异常的处理方法将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。
具体的,在一种可选的实施例中,在上述主题接口中还可以定义Add方法,通过调用该方法,一个IUncaughtExceptionObserver观察者可以实现对上述主题的订阅,即当异常信息发生时,调用主题类中的notify方法将异常信息发送至该观察者,所以在本方案中可以通过调用上述Add方法对上述分发记录中增加一条新的匹配处理模块的地址,上述新的匹配处理模块中预先定义有新的编程用户可能造成的异常的异常模式信息,当新的异常发生时,则本方案将异常信息同样发送至新的匹配处理模块,以便将异常信息发送至相应的编程用户。例如,在本方案的上述例子中,应用程序的开发人员主要分为IOS SDK开发人员和IOS APP的开发人员,当然一个应用程序可以由新的开发团队加入,当新的开发团队加入时,则可以调用上述Add方法增加一个新的匹配处理模块的地址。
本发明实施例二提供的异常信息的处理装置还可以包括:
移除模块28,用于将分发记录任意一条匹配处理模块的地址移除,形成新的分发记录,使得未处理异常的处理方法将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。
具体的,在一种可选的实施例中,在上述主题接口中还可以定义Remove方法,通过调用该方法,一个IUncaughtExceptionObserver观察者可以实现对上述主题的退阅,即当异常信息发生时,则不将上述异常信息发送至该观察者,所以在本方案中可以通过调用上述Remove方法对上述分发记录中移除一条新的匹配处理模块的地址,当新的异常发生时,则本方案不将异常信息同样发送至该匹配处理模块。例如,在本方案的上述例子中,应用程序的开发人员主要分为IOS SDK开发人员和IOS APP的开发人员,如果提前确认上述IOS SDK的开发人员提供的开发包不可能使应用程序出现异常时,则可以调用上述Remove方法移除该IOS SDK对应的匹配处理模块的地址。
下面本方案结合具体应用场景详细描述:
首先,本发明技术方案的技术原理为首先实现一个异常处理与分发的接口,该接口实现设计模式中的主题方面的接口,异常处理的类实现观察者模式中观察者方面的接口,当异常发生时,主题类通知该观察者类,同时利用观察者模式实现了分发和处理的解耦,方便以后扩展。
其次,本发明技术方案的整体思路为首先利用IOS API注册全局的未处理异常的处理方法,然后再该类的uncaughtException函数中通过主题类分发异常信息,观察者实现异常的特征的提取与匹配,如匹配将相关信息发送到自己。
具体的,为实现上述功能,在本方案中创建了主题接口,主题类、观察者接口和观察者类,上述类和接口的具体解释如下:
主题接口:IUncaughtExceptionSubject,可以通过调用这个接口的Add或者Remove方法,一个IUncaughtExceptionObserver观察者接口可以实现对该主题的订阅和退阅,同时当异常发生时IUncaughtExceptionSubject接口通过调用Notify通知相关观察者。
在主题接口中定义了三个方法如下:
Add(IUncaughtExceptionObserver)observer:该接口方法接受一个IUncaughtExceptionSubject参数,表示全局异常处理接口这个接口的订阅。
Remove(IUncaughtExceptionObservr)observer;该接口方法接受一个IUncaughtExceptionSubject参数,表示全局异常处理接口这个接口的退阅。
Notify With(Throwable)exception:这个接口方法接受一个异常类参数,通过调用该方法将这个异常类通知到所有订阅全局异常主题的订阅者。
主题实现类UncaughtExceptionSubjectImpl:这是一个对上述IUncaughtExceptionSubject接口的具体实现类。
观察者接口:全局异常的处理接口,通过实现该接口,开发人员就可以实现自己的全局异常处理(例如,检查当前的异常是否是自己的代码引起的等)。
在上述观察者接口中定义了如下方法:(bool)HandleUncaughtException:(NSException)exception。
观察者实现类UncaughtExceptionObserverImpl:是一个对上述IUncaughtExceptionObserver接口的具体实现类。
可选的,结合部分代码描述本方案:
在IOS APP启动时调用如下方法:
其中UncaughtExceptionHandler是一个处理异常的全局方法定义如下:
UncaughtExceptionHandler方法如下:
通过以上方法,调用uncaughtExceptionSubject全局异常主题的Notify方法通知注册该主题的所有订阅者。
其中UncaughtExceptionObserverImpl是一个具体的全局异常的订阅者,实现思路如下:在(bool)HandleUncaughtException:(NSException)exception方法中检测提取异常的相关信息,如:在异常的堆栈中提取异常程序集名称,异常类名称,异常函数名称,根据这些信息判断相关信息是否与当前观察者定义的模式匹配,如果匹配相关观察者类实现者将该信息发送给自己。
本申请提供的方案的关键点在于,在全局的未捕获异常处理器中处理相关异常。通过观察者模式跟踪异常发生的相关情况。在观察者中提取相关特征并匹配。匹配成功交通知相关负责人。
这里需要说明的是,本文中所提到的相关负责人可以为软件的开发人员、软件的编程用户,也即本文中的观察者。
综上,本申请提供的方案优点如下:
(1)因为本方案能把不同开发人员开发的代码的异常分发给相关开发人员,所以避免了大家一起对某个异常同时关注而造成的时间损耗,提高了效率。
(2)提高了SDK开发人员发现问题与解决问题的效率。
(3)提高了APP开发人员发现问题与解决问题的效率。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置,可通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、移动终端、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。