我正在开发一个ASP.NET web应用程序。我正在为整个应用程序实现日志记录框架。
web应用程序大约有7-8页,是一个简单的CRUD操作web应用程序。
它是Azure托管的应用程序。下面是我用来记录日志和处理异常的方法。
1)在数据访问层增加Try...Catch块,点击事件。
2)在捕获错误时,我将异常向上传播到Globabl.asax级别,并在Application_Error事件中将错误记录到事件日志和跟踪日志中。
3)之后,在Global.asax文件中,我将重定向到错误页面,以显示用户友好的消息和指向失败页面的链接。
4)我只是想知道这是不是一个好的方法。
谢谢朋友们。
发布于 2012-03-20 23:26:52
你是否真的在DAL上处理异常(例如,日志记录,试图修复它,等等)?如果不是,那么try catch除了旋转循环之外没有其他用途。单击事件也是如此,但在UI上处理错误并不是一种糟糕的做法,即使您并没有真正对它们做任何事情,因为您会将用户从丑陋的错误页面转移到您自己的友好消息上。
如果您确实无法处理抛出的异常,则可以使用单个错误页面。好处是上市时间,因为您编写了宝贵的小代码,以避免向用户显示丑陋的消息。缺点是用户错过了上下文。除了作为备份(有一个我没有预料到的错误,已经超过了我的第一行处理程序),我并不是真的在一个适合所有异常处理程序的大小上。
如果您基于HTTP状态进行处理,那么有一种常见错误页面的变体,即使用config。
另一种模式是设置您自己的基页,并让它作为错误处理程序工作。然后,您可以留出一个容器,以便在发生错误时进行填充。这种方法可以很好地添加上下文,因为用户仍然可以看到他所在页面的一部分,但您已经给出了一条错误消息,所以他知道事情已经失败了。我见过当发生错误时添加到容器中的用户控件使用的这种模式,但这有点复杂,因为您必须设置一个包含代码和适当消息的表来显示(这本身可能有but )。
发布于 2012-03-20 23:25:12
为什么不使用ASP.NET自定义错误页面?可以为每个状态代码指定每个错误页,也可以指定默认重定向。
您可以在web配置中对其进行配置,这样就完成了所有设置。
<customErrors defaultRedirect="GenericError.htm" mode="On">
<error statusCode="404" redirect="notfound.htm"/>
</customErrors>您可以将其配置为向所有用户或仅向远程用户显示自定义错误页面等。
http://aspnetresources.com/articles/CustomErrorPages
我完全同意您应该在catch块中记录所有错误,并将其写入日志。
发布于 2012-03-20 23:31:15
这听起来像是你在重新发明轮子。ASP.NET已经包含了一些可以帮助你达到预期效果的东西。除非您需要处理逻辑以便在错误发生后进行清理,否则我不会使用try catch块。看看用于记录错误的ASP.NET Health Monitoring Overview。有关显示自定义错误页面的信息,请参阅How to create custom error reporting pages in ASP.NET by using Visual C# .NET。
https://stackoverflow.com/questions/9789581
复制相似问题