一、返回错误信息和错误码,这样客户端可以把错误信息直接显示给用户,省去了解析错误码的烦恼。
服务器端实现:
下面的类解析错误码定义文件,并且把错误信息加入hastTable

































































































































异常抛出方式:
























客户端如果检测到是MeetingBaseException就可以直接把错误信息显示给客户,而不用解析错误码。
缺点:虽然省去了错误码的解析,但是如果有多语言化问题,错误信息直接显示就不行了。
如果客户端想只显示某些错误信息给客户,这种方式也不方便。
二、只返回错误码,客户端去解析错误码,这样提供了,最大的灵活性。
实现:服务器省去了错误码的解析。
异常抛出方式:

下面是用到资源文件的例子,如果只有一种资源,就可以用ErrProcedure处理。
因为全局资源被编译为资源类,而错误码是数字,不能做标志符,因此把他做简单处理,正数前加“R”,负数加“R_”,修改后类似(简体资源):



<data name="R_500" xml:space="preserve">
<value>系统异常</value>
</data>

























此处用反射简化了很多,见 http://www.cnblogs.com/bluewater/archive/2006/09/08/498660.html
我认为第二种方式在大多数情况下都比较好,如果是很小的项目,第一种方式会简单些。
webservice异常处理:
在webservice中抛出异常,让客户端去解析是很困难的,因为客户端可能是js,php等,对ws的封装很差。因此我认为好一些的异常处理应该这样:
返回结果分两种类型,一种是只包含简单的错误码:










































[WebMethod()]
public SoapResult FreeConfrence()

{
try

{
mc.FreeConfrence();
return new SoapResult(0);
}
catch (MeetingBaseException me)

{
return new SoapResult(me.ErrCode);

}
catch (ApplicationException ae)

{
Log4net.log.Error(ae);
return new SoapResult(-500);
}

catch (Exception e)

{
if (e.InnerException != null)

{
Log4net.log.Error(e.InnerException);
}
Log4net.log.Error(e);
return new SoapResult(-500);
}
}
另一种返回复杂结果:

public SoapResult FreeConfrence()








































先定义返回值类型如,HistoryFeeResult
























































实现方式和第一种一样,只是如果有自定义异常,则调用HistoryFeeResult的只有错误码的构造函数。
如果调用成功会返回(Post方式):






















