【分享|转贴】三层结构中的错误处理
异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被
转化为业务执行的结果。
1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。
2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出
异常,而是返回(或通过out参数)一个表示验证结果的枚举值,这属于业务执行的结果。但是,如果在从数
据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。
3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业
务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系
统异常,并将其解释为友好的错误信息呈现给用户。
原地址:http://www.cnblogs.com/zhuweisky/archive/2007/04/02/697195.html
欢迎大家踊跃发言,谈谈自己在项目中的做法.
------解决方案--------------------我自己写个方法!放到dll中调用。http://data.v5star.com
------解决方案--------------------正迷糊这个呢,好好看看~~~
------解决方案--------------------:)
------解决方案--------------------mark
------解决方案--------------------还好吧,有点明白!
------解决方案--------------------不完全赞同其上观点.例如4.UI层原则上不该捕获任何异常.本研发部(CMM5)为公司提供的开发框架文档对此有专门解释.
------解决方案--------------------up
------解决方案--------------------如果是个人的项目,想怎么都行。如果是公司项目,宝玉那个也够用了。难道这也弄个统一标准??
------解决方案--------------------三层架构 忘得差不多了 有复习了下 帮顶了
------解决方案--------------------学习
------解决方案--------------------很好,不管怎么样,即使要把系统异常转化为业务异常,也要记得把异常信息记录下来。
如果单纯try catch还不如什么都不做,让异常上跑到表现层,使用customError把用户转到统一出错页面
并且通过httpModule插件形式记录所有未处理异常,每天看看各大网站有没有什么异常一来可以修复BUG而来可以看是不是有人在捣乱
比如
C# code
public class ExceptionModule : IHttpModule
{
#region IHttpModule 成员
public void Init(HttpApplication application)
{
application.Error += new EventHandler(OnError);
}
public void Dispose()
{
}
#endregion
/// <summary>
/// 错误处理
/// </summary>
/// <param name="sender"></param>
/// <param name="args"></param>
public void OnError(object sender, EventArgs args)
{
HttpApplication application = (HttpApplication)sender;
te_ExceptionLog log = GetExceptionLog(application.Server.GetLastError(), application.Context);
string ExceptionProcessWay = ConfigurationManager.AppSettings["ExceptionProcessWay"];
IExceptionProcess server = (IExceptionProcess)Activator.GetObject(typeof(IExceptionProcess), ConfigurationManager.AppSettings["ETSRemotingURL"].ToString());
server.LogException(log, ExceptionProcessWay);
}