一种输出异常的方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种输出异常的方法及装置。

背景技术：

为满足人们日益增加的生活需求，当前，诸多的线上平台相继推出了各种功能强大、操作简单的线上业务，并将这些线上业务以网站、应用(Application，App)等形式呈现在用户面前，相应的，用户可使用自己所持有的终端设备随时随地的使用这些线上业务，以解决自身所遇到的实际问题。

各项业务在实际运行中都不可避免的会出现运行异常的情况，一般情况下，业务处理过程中所出现的异常大致可以分为两类，第一类称为系统自身异常，这类异常通常是由运行业务的服务器(系统)本身所引起的，如服务器(系统)自身出现运行故障而最终导致该业务出现异常，或是服务器(系统)本身在处理该业务的过程中，出现了诸如业务逻辑错误、业务代码出错等情况而致使该业务出现异常；第二类称为非系统自身异常，这类异常通常是指，在实际应用中，服务器(系统)在运行该业务的过程中，有时需要通过调用其他服务器(系统)来完成该业务的处理工作，而若在调用过程中，其他服务器(系统)出现了诸如运行故障、处理该业务出错等情况则也会致使该业务出现异常。

对于上述说明的两类异常，通常情况下，当该业务出现异常时，运行该业务的服务器(系统)通常需要捕获出现的异常信息，并将捕获的异常信息经过一定的处理后输出，以呈现给线上业务的维护人员或用户。而对于第二类异常来说，通常情况下，当服务器(系统)所调用的其他服务器(系统)出现异常时，该其他服务器(系统)可针对出现的异常而生成的异常信息发送给该服务器(系统)，而该服务器(系统)在接收到其他服务器(系统)发送的该异常信息后(相当于捕获了该异常信息)，可对该异常信息的具体内容进行识别，并将识别出的结果呈现给线上业务的维护人员或用户查看。

例如，假设业务A需要依次经过服务器(系统)B和服务器(系统)A的处理后，最终由服务器(系统)A输出处理结果，这其中，服务器(系统)B在处理该业务A时出现了异常，则服务器(系统)B可针对出现的异常，生成对应该异常的异常信息，并将该异常信息发送给服务器(系统)A，服务器(系统)A在接收到服务器B发送的异常信息后(相当于捕获了该异常信息)，可识别出该异常信息的具体内容，并将识别出的结果向线上业务的维护人员或用户呈现。

然而，在实际应用中，各服务器(系统)所发送的异常信息中包含的数据往往在格式上都各不相同，若运行该业务的服务器(系统)没有与其他服务器(系统)约定转换异常信息的协议，当服务器(系统)接收到其他服务器(系统)发送的异常信息后，由于该异常信息中包含的数据在格式上可能并不是该服务器(系统)所能识别出的数据格式，所以，即使该服务器(系统)接收到了该异常信息，也将无法识别该异常信息，即，服务器(系统)可确定出接收到的信息为异常信息，但是并不能确定出该异常信息的具体内容，从而也将无法对该异常信息进行处理和输出，这就给线上业务的维护人员或用户在查看该异常信息过程中带来了困难。

技术实现要素：

本申请实施例提供一种输出异常的方法，用于解决现有技术会给线上业务的维护人员或用户在查看异常信息的过程中带来不便的问题。

本申请实施例提供一种输出异常的装置，用于解决现有技术会给线上业务的维护人员或用户在查看异常信息的过程中带来不便的问题。

本申请实施例采用下述技术方案：

本申请实施例提供一种输出异常的方法，包括：

第一节点接收第二节点发送的异常信息；

判断所述异常信息中包含的数据的格式是否为标准格式；

若是，则输出所述异常信息；

若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

本申请实施例提供一种输出异常的方法，包括：

转换节点接收第一节点发送的异常信息；

判断所述异常信息中包含的数据的格式是否为标准格式；

若是，则将所述异常信息发送给第二节点；

若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并将转换后的异常信息发送给所述第二节点。

本申请实施例提供一种输出异常的装置，包括：

接收模块，接收第二节点发送的异常信息；

判断输出模块，判断所述异常信息中包含的数据的格式是否为标准格式；若是，则输出所述异常信息；若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

本申请实施例提供一种输出异常的装置，包括：

接收信息模块，接收第一节点发送的异常信息；

判断发送模块，判断所述异常信息中包含的数据的格式是否为标准格式；若是，则将所述异常信息发送给第二节点；若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并将转换后的异常信息发送给所述第二节点。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

由于本申请实施例中，节点可通过预先设置的格式转换规则，将上一个节点发送的异常信息中包含的数据转换为标准格式的数据，使得该节点在确定出接收到的信息为异常信息的同时，也能够确定出该异常信息的具体内容，相应的，由于该异常信息中的数据在格式上已经被该节点转换成了各节点均可识别出的数据格式，所以，后续其他节点在接收到转换后的异常信息时，也同样可以确定出该异常信息的具体内容，从而将识别出的异常信息经过一定的处理后呈现给用户，进而避免了因节点无法识别其他节点发送的异常信息而导致的线上业务的维护人员或用户无法查看到异常信息的问题，并提高了异常信息的传输效率，节省了各节点的资源。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的输出异常的过程；

图2为本申请实施例提供的拦截器的设置示意图；

图3为本申请实施例提供的设有统一拦截器的业务链路示意图；

图4为本申请实施例提供的通过中间件来实施的输出异常的方法；

图5为本申请实施例提供的包含有转换节点的业务链路示意图；

图6为本申请实施例提供的设有多个转换节点的业务链路示意图；

图7为本申请实施例提供的包含有转换节点和拦截器的业务链路示意图；

图8为本申请实施例提供的一种输出异常的装置示意图；

图9为本申请实施例提供的另一种输出异常的装置示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请实施例提供的输出异常的过程，具体包括以下步骤：

S101：第一节点接收第二节点发送的异常信息。

在实际应用中，一项业务的执行往往需要多个节点共同来完成，换句话说，一个节点在接收到用户发送的业务请求后，通常还需要调用其他的节点来完成该业务请求的处理工作，而无论是接收该业务请求的节点，还是其他节点，在处理该业务请求时，都有可能会有运行异常的情况出现，其中，这里出现的异常一方面可能是节点本身的运行状况所导致的，另一方面可能是节点在处理该业务请求时，出现的诸如业务逻辑出错、业务代码出错等状况所导致的。

对于异常出现的情况来说，为了使线上业务的维护人员或用户能够通过查看该异常对应的异常信息来得知业务的执行过程中到底出现了何种的异常，节点在处理该业务请求的过程中出现异常时，通常需要针对出现的异常而生成相应的异常信息，并将该异常信息进行输出，其中，若该节点为业务链路上最终输出业务处理结果的节点，则该节点在捕获到异常并生成相应的异常信息后，可将该异常信息进行输出，以呈现给线上业务的维护人员或用户进行查看。而由于本申请实施例意在解决因该节点无法识别其他节点发送的异常信息而导致不能将该异常信息呈现给线上业务维护人员或用户的问题，因此，对于该节点并非业务链路上最终节点的这种情况来说(即该节点并非为最终输出业务处理结果的节点)，当该节点在执行该业务请求的过程中出现异常时，该节点可捕获该异常并生成对应该异常的异常信息，而后，该节点可将该异常信息发送给该节点在业务链路上对应的下一个节点，为了方便后续的说明，在本申请实施例中，生成异常信息的节点可以称为第二节点，而接收第二节点发送的异常信息的节点可以称为第一节点，所以，当第二节点将生成的异常信息发送给第一节点时，第一节点也将相应的接收第二节点发送的异常信息。

需要说明的是，这里提到的节点可以是业务链路上的服务器或是系统，即，该业务链路上存在多个服务器或系统，用户发送的业务请求需要经过该业务链路上的多个服务器或系统的处理后，最终由该业务链路上最终输出业务处理结果的服务器或系统输出业务处理结果。除此之外，本申请实施例中提到的节点也可以是一个服务器中的一个处理单元或处理模块，即，业务链路中的各节点可以是一个服务器中包含的各处理单元或处理模块所构成的，其中，这些处理单元或处理模块除了可以是硬件设备外，还可以是诸如程序等软件。当然，业务链路上的各节点也可以多个服务器或系统中包含的各处理单元或处理模块构成的。

S102：判断所述异常信息中包含的数据的格式是否为标准格式，若是，则执行步骤S103，若否，则执行步骤S104。

S103：输出所述异常信息。

S104：根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

在实际应用中，业务节点针对出现的异常而生成的异常信息中除了包含有基本的异常类信息外，还通常包含有诸如错误码、错误描述等数据，例如，System.OverflowException、Format Exception这两个就是异常信息中包含的基本的异常类信息，而对于0x80040277这样的信息，则属于异常信息中包含的错误码信息。通常情况下，异常信息中包含的基本的异常类信息基本都是通用的，换句话说，异常类信息对于不同的节点往往都是相同的，各节点通常能识别出异常信息中包含的基本的异常类信息，所以，一个节点在接收到包含有异常类信息的信息时，通常都能根据该异常类信息，确定出接收到的信息是一个异常信息。但是，对于异常信息中包含的诸如错误码、错误描述等这样的数据来说，不同的节点针对同一异常所生成的异常信息中包含的错误码等数据可能都是不同的，例如，对于业务A出现的某一异常来说，节点A针对该异常而生成的异常信息中包含的错误码可能是0x79996730，而对于节点B来说话，节点B针对该异常而生成的异常信息中包含的错误码却是0x73236012，这样一来，当节点A将其针对某一异常而生成的异常信息发送给节点B时，由于节点B针对该异常的而生成的错误码与节点A不同，所以，节点B在接收到该异常信息后，节点B可通过该异常信息中包含的基本的异常类信息确定出该信息是一个异常信息，但是由于无法识别出该异常信息中的错误码等数据，节点B因此将不能进一步的确定出该异常信息的具体内容，进而也就无法对该异常信息做进一步的处理。

通常情况下，节点与节点之间通常都会针对同一异常预先约定转换协议，即，对于事先以对同一异常进行转换约定的两个节点来说，当节点将针对该异常而生成的异常信息发送给另一个节点时，另一个节点可根据预先约定的转换协议，将该异常信息中包含的诸如错误码、错误描述等数据转换成自己所能识别的错误码、错误描述等数据，进而通过识别转换的错误码、错误描述等数据来确定出该异常信息的具体内容。但是，在实际应用中，节点与节点仅会针对一些异常预设约定转换协议，而对于没有事先约定转换协议的异常来说，当一个节点将针对这种异常而生成的异常信息发送给另一个节点时，由于这两个节点没有事先约定针对该异常的转换协议，所以，另一个节点在接收到该异常信息后，也将无法识别出该异常信息中包好的诸如错误码、错误描述等数据，相应的也就无法确定出该异常信息的具体内容。

因此，为了避免上述问题的发生，在本申请实施例中，每个节点也可设置一个针对自身的格式转换规则，并当接收到其他节点发送的异常信息时，根据预设的针对自身的格式转换规则，将该异常信息中包含的数据转换成自己所能识别的数据，进而得到自己能够识别出的转换后的异常信息，其中，这里提到的格式转换规则可以是：节点可通过该格式转换规则，将不同节点发送的同一异常信息转换成自己所能识别的统一的异常信息，并且，节点可通过该格式转换规则将所有的异常信息都转换成自身所能识别的异常信息，而不像现有技术中那样只单单针对一部分异常信息。

例如，一条业务链路上存在U、I、O这三个业务节点，每个节点都有针对自身的一套格式转换规则，因此，当节点U在进行业务执行的过程中出现异常时，可将针对该异常而生成的异常信息发送给节点I，而节点I在接收到节点U发送的异常信息后发现，该异常信息中包含的数据的格式并不是自己所要求的标准格式，因此，节点I可根据预设的针对自身的一套格式转换规则，将该异常信息中包含的数据转换成自己所能识别出的数据，并将转换后的异常信息发送给后续的节点O，相应的，节点O在接收到节点I发送的转换后的异常信息后发现，该转换后的异常信息中包含的数据的格式也不是自己所要求的标准格式，因此，节点O可根据预设的针对自身的一套格式转换规则，将该转换后的异常信息中包含的、对应节点I所规定的标准格式的数据，转换成针对自身(节点O)所规定的标准格式的数据，并最终将完成转换的异常信息进行输出，其中，各节点中预设的格式转换规则，可以是针对所有节点的标准格式与自身标准格式的一套完整的对应关系，而若各节点在业务链路上接收的异常信息、业务处理结果等都是由固定的节点发送的，即，在业务链路上各节点之间的调用关系都是固定不变的，则各节点中预设的格式转换规则可以是一个自身规定的标准格式与和它存在固定调用关系的节点所规定的标准格式的对应关系。

然而，通常情况下，节点与节点之间的调用关系往往并不是固定的，例如，对于一项业务来说，节点1在接收到用户发送的业务请求后，往往需要通过识别出的该业务请求的内容，决定后续需要将该业务请求发送至哪一节点来继续处理，所以说，对于两个业务请求来说，虽然这两个业务请求都是由节点1接收的，但是若这两个业务请求的内容不同，节点1后续也可能会分别将这两个业务请求发送至不同的节点，相应的，倘若节点1在处理业务请求的过程中出现了异常，则通常也需要根据业务请求的内容来决定生成的异常信息应发送至哪个节点中，也就是说，节点1通常是对应多个节点的，所以，对于节点1来说，为了能够使它(节点1)对应的节点能够识别出自己(节点1)发送的异常信息，该节点1事先需要分别和其对应的各节点约定格式转换规则，并且，各格式转换规则往往都只适用于相互约定的两个节点，因此，这不仅极大的增加了异常信息的传输复杂度(即，由于各节点之间分别都相互约定了格式转换规则，所以，异常信息每到一个节点就需要转换一次)，并且，各节点需要将与其他节点约定的各格式转换规则进行存储，所以，业务链路上的节点越多，每个节点事先需要存储的格式转换规则也就越多，也就越占用各节点的存储空间，同时，由于异常信息每到一个节点就需要转换一次，这就极大的增加了各节点的资源消耗，从而降低了异常信息的传输效率。

为了避免上述问题的出现，在本申请实施例中，各节点可预先设置同一的格式转换规则，并通过该格式转换规则，来识别异常信息中包含的各数据(如，错误码、错误描述等数据)，后续过程中，节点在接收到其他节点发送的异常信息时，可根据预设的格式转换规则，将该异常信息中包含的数据的格式转换为标准格式，并输出转换后的异常信息，这样，其他的节点在接收到该转换后的异常信息后，由于该异常信息中包含的数据的格式已经为转换后的标准格式，所以，其他的节点均可识别出该异常信息中包含的数据，进而确定出该异常信息的具体内容，同时，该异常信息无需每经过一个节点就进行转换异常，只需经过一次的转换，即可使后续的节点均可识别出该转换后的异常信息，从而极大的提高了该异常信息的传输效率，节省了节点的资源，并且节省了各节点的存储空间。

具体的，第一节点在接收到第二节点发送的异常信息后，可先判断该异常信息中包含的数据的格式是否为标准格式，若是，则说明该异常信息已经经过了标准转换，进而直接将该异常信息输出即可，而当第一节点判断出该异常信息中包含的数据的格式并非标准格式时，为了保证后续的节点能够有效的识别出该异常信息中包含的数据，该第一节点可根据预设的格式转换规则，将该异常信息中包含的数据转换为标准格式的数据，其中，在数据格式的转换过程中，第一节点可先确定出该异常信息的异常类型，此举的目的在于，在实际应用中，节点所捕获的异常通常分为若干个异常类型，而对于同一种异常类型的不同异常信息来说，各异常信息中包含的诸如错误码、错误描述等数据往往也是彼此不同的，换句话来说，异常通常是分为若干个异常类别的，而不同的异常信息分别归属于各自所属的异常类别中，而对于预先设置的格式转换规则来说，倘若该格式转换规则没有按照异常类型进行相应的分类，而是将针对所有的异常信息设置一个统一的格式转换规则，则节点会不分类别的将所有的错误码、错误描述等数据与标准数据的转换关系进行一一记录，相应的，节点后续在对异常信息中的数据进行格式转换时，也将遍历预先设置的各转换关系，并在找到后再对异常信息中的数据进行格式转换，所以，对于这种情况来说，若预先设置的格式转换规则中记录的数据转换关系越多，节点需要遍历这些数据转换关系所消耗的时间也就越长，转换数据的效率也就越低。

所以，为了避免上述情况的发生，在本申请实施例中，线上业务的维护人员可针对不同的异常类型，设置不同的格式转换规则，不同的格式转换规则可对应一种异常类型的异常信息，而后，线上业务维护人员可将针对不同异常类型而设置的各格式转换规则录入到各节点中。相应的，由于各节点事先已经都保存了预设的各格式转换规则，因此，当第一节点在对第二节点发送的异常信息进行转换之前，第一节点可先确定出该异常信息的异常类型，而后，第一节点可根据确定出的异常类型，在预设的各格式转换规则中确定出与该异常类型对应的格式转换规则，并当确定出相应的格式转换规则后，将该异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

需要说明的是，线上业务的维护人员在查看到节点最终输出的异常信息后，通常需要了解该异常信息到底是谁生成的，换句话说，整个业务执行下来，到底是在哪个业务节点上出现了问题，因此，在本申请实施例中，第一节点在接收到第二节点发送的异常信息后，可针对该异常信息创建对应于该异常信息的错误堆栈，并将该第二节点对应的节点标识压入到该错误堆栈中，并输出该异常信息，其中，这里提到的节点标识可以是服务器标、系统标识，或是处理单元、处理模块的标识等，不仅如此，这里提到的第二节点对应的节点标识压入到该错误堆栈中并不意味着该异常信息就是第二节点生成的(即并不意味着异常就发生在第二节点中)，而是指该异常信息无论是否是第二节点生成的，第一节点所接收到的该异常信息都是由第二节点发送过来的，相应的，若后续第一节点需要将该异常信息再次发送给第三节点(该第三节点是位于业务链路上的第一节点的下一个节点)时，第三节点可将第一节点对应的节点标识也压入到该错误堆栈中，并输出该异常信息。这样一来，线上业务的维护人员后续可通过查看该错误堆栈，来梳理出整个业务链路，并根据该错误堆栈中记录的节点标识，找到在该业务链路上出现异常的源头，并对其进行相应的修复，其中，由于各节点标识都是依次压入到错误堆栈中的，因此，当这个业务执行过程中，仅出现一个异常的情况时，位于错误堆栈中最低处的节点标识则应是该业务执行过程中异常出现的源头。

还需说明的是，通常情况下，若第二节点为异常出现的源头节点，则第一节点在接收到第二节点发送的异常信息时，可创建出对应于该异常信息的错误堆栈，并该错误堆栈以信息的形式附带在该异常信息输出至下一个节点，相应的，而下一个节点在接收到第一节点发送的异常信息后，可将第一节点对应的节点标识压入异常信息中的错误堆栈中，并输出至下一个节点，直至将该异常信息输出至业务链路上的最终节点处。而对于信息形式的错误堆栈来说，不同的节点生成的错误堆栈在信息格式上可能也会存在不同，因此，在本申请实施例中，线上业务的维护人员也可针对信息形式的错误堆栈设置一个统一的转换规则，并将该转换规则录入到各节点中，后续节点在接收到其他节点发送的异常信息时发现该异常信息中包含的信息形式的错误堆栈在格式上不符合预设的标准格式，则可根据预设的转换规则，将该信息形式的错误堆栈转换成标准格式的错误堆栈，并将转换后的信息形式的错误堆栈附带在异常信息输出。这样一来，由于转换后错误堆栈上在格式上为各节点均可识别的标准格式，所以，后续的节点均可识别出该信息形式的错误堆栈，并将对应自己的前一个节点的节点标识压入到该错误堆栈中来完成该错误堆栈的更新工作。

通常情况下，异常信息的异常类型通常可以分为两大类，第一类指的是针对业务方面上的异常类型，第二类指的是一些公用的异常类型，如网络连接异常等。对于这两大类异常类型来说，在本申请实施例中，节点可只针对第一类异常类型的异常信息进行转换，而对于第二类异常类型的异常信息来说，节点可以不捕获这类异常类型的异常信息，而是将这类异常类型的异常信息交给指定的拦截器来统一进行处理。具体的实施过程可以是：第一节点在接收到第二节点发送的异常信息后，可先判断该异常信息的异常类型是否为指定的异常类型，这里提到的指定的异常类型指的是上述提到的第一类异常类型，即针对业务方面上的异常类型，当第一节点确定该异常信息的异常类型为该指定的异常类型时，则可根据预设的格式转换规则，将该异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息，而当第一节点确定出该异常信息的异常类型并非是指定的异常类型时，即该异常信息的异常类型为第二类的异常类型(公用的异常类型)，则可将该异常信息发送给后续节点，直至该异常信息被预设的拦截器拦截并转换成标准格式的异常信息输出，如图2所示。

图2为本申请实施例提供的拦截器的设置示意图。

在图2中，拦截器设置在业务链路上最终节点E之前，这样，当节点B(第一节点)接收到节点A(第二节点)发送的异常信息后发现，该异常信息的异常类型并不是指定的异常类型(即公用的异常类型)，则节点B可将该异常信息发送给节点C，相应的，节点C在接收到该异常信息后发现，该异常信息的异常类型并不是指定的异常类型，则节点C可将该异常信息发送给后续的节点，直至该异常信息传输至拦截器时，拦截器可将该异常信息转换为标准格式的异常信息，并将该转换后的异常信息发送给节点E，使得节点E在接收到转换后的异常信息后，可将该转换后的异常信息进行输出，以供线上业务的维护人员或用户进行查看。

需要说明的是，拦截器的位置也可以设置在其他位置，如设置在图2中的节点B和节点C之间，或是设置在节点C和节点D之间，而对于拦截器的数量也没有固定的限制，可以在每两个节点之间就设置一个拦截器，从而保证在执行一个业务的过程中，即使各节点分别出现了不同的公用异常(即第二类异常类型的异常)，各拦截器能够准确的将各节点分别出现的不同异常信息进行拦截，并转换成标准格式的异常信息输出至后续的节点中。当然，为了节省资源，对于多个节点会分别出现不同的公用异常的情况来说，可设置一个统一的拦截器，并使得每个节点在将异常信息发送至下一个节点之前，先发送至该拦截器，并由该拦截器将处理后的异常信息发送至后续的节点中，如图3所示。

图3为本申请实施例提供的设有统一拦截器的业务链路示意图。

在图3中，节点a出现异常时，可将针对该异常而生成的异常信息发送至节点b，节点b在接收到节点a发送的异常信息后发现，该异常信息b的异常类型并不是指定的异常类型(即该异常信息的异常类型为公用的异常类型)，因此，节点b可将该异常信息发送至拦截器中。拦截器在接收到该异常信息后，可将根据预设的格式转换规则，将该异常信息中包含的数据的格式转换为标准格式，并将转换后的异常信息发送至节点c，由于异常信息通常都是携带在节点自身处理业务请求后所得到的处理结果中的，因此，为防止节点c在处理业务请求的过程中也出现了异常，节点c在接收到该异常信息后，可将携带有该异常信息的处理结果发送给拦截器，拦截器在接收到节点c发送的处理结果后，可将该处理结果中的异常信息过滤出来，并判断过滤出的公用异常类型的异常信息中包含的数据是否为标准格式的数据，若是，则说明该异常信息先前已经经过了拦截器的标准转换处理，若否，则说明该异常信息先前没有经过拦截器的标准转换处理，换句话说，由于节点c并非是图3所示的业务链路上的最初节点，所以，拦截器接收到的节点c发送的公用异常类型的异常信息应是节点c自身生成的，也就是说，节点c在处理该业务请求的过程中出现了公用的异常，并相应的生成了公用异常类型的异常信息。所以，经过统一拦截器转换的各公用异常类型的异常信息可被业务链路上的最终节点e有效的识别出，继而保证了最终节点e对于异常信息的有效输出。

需要说明的是，上述说明的拦截器可以是一个独立的设备，如服务器、终端等，当然，该拦截器也可以是服务器或终端中的一个单元或模块等。

在实际应用中，若用户发送的业务请求只需要经过一个节点的处理即可完成，则即使节点在处理该业务请求的过程中出现了异常，节点也无需对该异常所对应的异常信息进行转换，因此，本申请实施例所描述的方法应是在一个业务请求需要经过多个节点的处理后而完成的前提下实施的，所以，本申请实施例所提供的输出异常的方法应适合于多节点调用的场景，如，面向服务的体系结构(Service-Oriented Architecture，SOA)。

从上述方法中可以看出，由于节点可将异常信息中包含的数据转换成各节点均可识别的标准格式的数据，因此，后续其他的节点在接收到转换后的异常信息后，同样可通过识别该异常信息中包含的数据而确定出该异常信息的具体内容，从而有效的避免了因节点无法识别其他节点发送的异常信息而导致的线上业务的维护人员或用户无法查看到异常信息的问题，给线上业务的维护人员或用户在查看该异常信息时带来了方便，并且，由于异常信息只需转换一次就能是其他节点均能识别出该转换后的异常信息，所以极大的提高了异常信息的传输效率，节省了各节点的资源。

在上述说明的方法中，将异常信息中的数据转换成标准格式的数据是由各节点来完成的，而为了提高节点处理业务请求的效率，节省节点的资源，也可设置一个专用用于进行异常信息转换的中间件，并通过该中间件，来保证各节点均能识别出接收到的异常信息，下面将针对这种情况进行详细说明。

图4为本申请实施例提供的通过中间件来实施的输出异常的方法，具体包括以下步骤：

S401：转换节点接收第一节点发送的异常信息。

在本申请实施例中，为了保证业务链路上的各节点能够有效的识别出各节点所生成的异常信息，可设置一个转换节点来将各节点所生成的异常信息中包含的数据转换成标准格式的数据并输出，其中，这里提到的转换节点就是上述提到的一个专门用于进行数据格式转换的中间件，因此，在本申请实施例中，第一节点在生成异常信息后，可将该异常信息附带在自身处理用户发送的业务请求后得到的处理结果中，并发送给该转换节点，相应的，为了保证业务链路上后续节点能够识别出第一节点生成的异常信息，转换节点则需要将第一节点发送的异常信息进行接收，如图5所示。

图5为本申请实施例提供的包含有转换节点的业务链路示意图。

在图5中，节点X处理用户发送的业务请求时出现了异常，则节点X可针对出现的异常而生成一个相应的异常信息，并将该异常信息发送给转换节点，相应的，转换节点则需要接收节点X发送的异常信息，以保证该异常信息后续能够在该业务链路上顺利的传输。

当然，在本申请实施例中，也可在业务链路上每两个节点之间就设置一个转换节点，如图6所示。

图6为本申请实施例提供的设有多个转换节点的业务链路示意图。

在图6中，业务链路上的每两个节点之间都设有一个转换节点，这样，当节点X在处理用户发送的业务请求过程中出现了异常时，则节点X可将针对该异常而生成的异常信息经过转换节点发送给节点Y，该异常信息在经过节点X与节点Y之间的转换节点时，可由转换节点将其(异常信息)包含的数据转换成标准格式的数据并输出转换后的异常信息，使得节点Y在接收到该异常信息后，在确认出该信息是一个异常信息的同时，还能有效的确定出该异常信息的具体内容，进而保证了节点Y能够顺利的将该转换后的异常信息传输至后续的节点中。不仅如此，由于每两个节点之间都设有一个转换节点，因此，当节点Y在执行业务的过程中，也出现了异常，则可将针对自身异常所生成的异常信息发送给后续的转换节点，使得转换节点在接收到节点Y发送的异常信息后，可将该异常信息中的数据转换成标准格式的数据，并将转换后的异常信息发送给后续的节点，这样就保证了业务链路上的各节点均能够有效的识别出前一个节点所发送的异常信息，进而保证了异常信息的最终输出。

需要说明的是，这里提到的第一节点以及后续提到的第二节点与上述步骤S101中提到的第一节点和第二节点是有所区别的，步骤S101中提到的第一节点是接收异常信息的，第二节点是发送异常信息的，而步骤S401中提到的第一节点是发送异常信息的，后续提到的第二节点是接收异常信息的，这里应加以区分，不要混淆。

S402：判断所述异常信息中包含的数据的格式是否为标准格式，若是，则执行步骤S403，若否，则执行步骤S404。

S403：将所述异常信息发送给第二节点。

S404：根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并将转换后的异常信息发送给所述第二节点。

转换节点在接收到第一节点发送的异常信息后，可判断出该异常信息中包含的数据的格式是否为标准格式，若是，则说明该异常信息先前已经被转换过了，直接将该异常信息发送给第二节点即可，而若发现该异常信息中包含的数据的格式并不是标准格式，则说明该异常信息先前并没有经过转换，则可根据预设的格式转换规则，将该异常信息中包含的数据转换为标准格式的数据，具体转换过程可以是：转换节点可先确定出该异常信息的异常类型，并根据确定出的异常类型，在预设的格式转换规则中确定出与该异常类型相对应的格式转换规则，而后，转换节点可根据确定出的格式转换规则，将该异常信息中包含的诸如错误码、错误描述等数据转换为标准格式的数据，并将转换后的异常信息发送给第二节点，详细过程如上述步骤S202～S204所述，在此就不再赘述了。

需要说明的是，若转换节点确定出第一节点发送的异常信息中包含的数据已经为标准格式的数据时，则除了可将该异常信息直接发送给第二节点外，也可将该异常信息返回给第一节点，并由第一节点再将该异常信息发送给第二节点。而对于转换后的异常信息来说，转换节点除了将转换后的异常信息直接发送给第二节点外，还可将该转换后的异常信息返回给第一节点，并由第一节点将该转换后的异常信息发送给第二节点，即，将转换后的异常信息通过第一节点发送给第二节点。

另外，在本申请实施例中，转换节点在第一次接收到节点发送的异常信息后，可针对该异常信息创建相应的错误堆栈，并将发送该异常信息的节点标识压入到错误堆栈中，后续转换节点在接收到其他节点发送的该异常信息后，同样可将其他节点的节点标识按照接收顺序依次压入到该错误堆栈中，这样，后续线上业务的维护人员可通过查看转换节点所保存的错误堆栈，确定出到底是业务链路上的哪个节点出现了异常，进而对该异常进行修复。

在本申请实施例中，也可针对公用异常类型的异常信息设置一个拦截器，使得转换节点(中间件)和拦截器分别负责不同异常类型的异常信息的转换工作，如图7所示。

图7为本申请实施例提供的包含有转换节点和拦截器的业务链路示意图。

在图7中，节点在接收到其他节点发送的异常信息时，可将该异常信息发送给转换节点，而转换节点在接收到该异常信息后，可先确定该异常信息是否为指定异常类型的异常信息(即第一类异常：针对业务的异常)，若是，则进一步的判断该异常信息中包含的数据是否为标准格式的数据，并当确定出该异常信息中包含的数据为非标准格式的数据时，根据预设的格式转换规则，将该异常信息中包含的数据转换成标准格式的数据并输出转换后的异常信息，而当转换节点在接收到节点发送的异常信息后发现，该异常信息并非是指定异常类型的异常信息(即确定出该异常信息的异常类型为第二类异常：公用的异常)，则可将该异常信息直接输出，直到该异常信息传输至拦截器时，由拦截器将其进行拦截并将该异常信息中的数据转换为标准格式的数据进行输出。由于在图7中所示的业务链路中设置了用于处理公用异常类型异常信息的拦截器，因此极大的减轻了转换节点的运行负担，节省了转换节点的资源。

以上为本申请实施例提供的输出异常的方法，基于同样的思路，本申请实施例还提供了输出异常的装置，如图8、9所示。

图8为本申请实施例提供的一种输出异常的装置示意图，具体包括：

接收模块801，接收第二节点发送的异常信息；

判断输出模块802，判断所述异常信息中包含的数据的格式是否为标准格式；若是，则输出所述异常信息；若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

所述装置还包括：

创建模块803，创建对应于所述异常信息的错误堆栈；将所述第二节点的节点标识压入所述错误堆栈，并输出所述异常信息。

所述判断输出模块802，确定所述异常信息的异常类型；根据所述异常类型，在预设的格式转换规则中确定出与所述异常类型对应的格式转换规则；根据确定出的所述格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并输出转换后的异常信息。

所述判断输出模块802，判断所述异常信息的异常类型是否为指定的异常类型；若是指定的异常类型，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据；若不是指定的异常类型，则将所述异常信息发送给后续节点，直至所述异常信息被预设的拦截器拦截并转换成标准格式的异常信息输出。

所述装置用于面向服务的体系结构SOA中的异常信息输出。

图9为本申请实施例提供的另一种输出异常的装置示意图。

接收信息模块901，接收第一节点发送的异常信息；

判断发送模块902，判断所述异常信息中包含的数据的格式是否为标准格式；若是，则将所述异常信息发送给第二节点；若否，则根据预设的格式转换规则，将所述异常信息中包含的数据转换为标准格式的数据，并将转换后的异常信息发送给所述第二节点。

所述判断发送模块902，将所述异常信息通过所述第一节点发送给所述第二节点；

所述判断发送模块902，将所述转换后的异常信息通过所述第一节点发送给所述第二节点。

本申请实施例提供一种输出异常的方法及装置，该方法中节点可通过预先设置的格式转换规则，将上一个节点发送的异常信息中包含的数据转换为标准格式的数据，使得节点在确定出接收到的信息为异常信息的同时，也能够确定出该异常信息的具体内容，相应的，由于该异常信息中的数据在格式上已经被该节点转换成了节点均可识别出的数据格式，所以，后续其他节点在接收到转换后的异常信息时，也同样可以确定出该异常信息的具体内容，从而将识别出的异常信息经过一定的处理后呈现给用户，进而避免了因节点无法识别其他节点发送的异常信息而导致的线上业务的维护人员或用户无法查看到异常信息的问题，并提高了异常信息的传输效率，节省了各节点的资源。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S101和步骤S102的执行主体可以为第一节点中的接收模块，步骤103的执行主体可以为第一节点的发送模块；又比如，步骤101的执行主体可以为第一节点中的接收模块，步骤102和步骤103的执行主体可以为第一节点的判断输出模块；等等。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。