General way to handle exceptions

发布于 2022-11-15 14:02:58 字数 1353 浏览 0 评论 0

I'm trying to design the exception handling mechanism in my web app, and got into some difficulties in the design.

As much as I know - there are three ways to catch exceptions in ASP.NET app -

  1. In the code itself (try, catch, finally)
  2. In the Page_Error event of the page
  3. In the Application_Error event of the global.asax page

Since I have many events and functions in my .aspx pages, I wanted one single place that will catch and collect exceptions. In other words- I really don't feel like spreaindg try-catch statments all over the code, so I thought using the Page_Error event (which I read might be good practice at some cases).

However, a problem arises because all I want the exception handler to do is to show a nice alert on the page itself informing about general problem that took place, but as you probably know - when you get to Page_Error the page is already dead and failed to render.

So, what other generic way is there to catch exceptions, in a manner that when I will write functions in the future I won't need to think about exceptions or try-catch, but instead know that there is a mechanism somewhere out there that will catch everything and handle it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

三岁铭 2022-11-22 14:02:58 6 楼

Use Elmah - http://code.google.com/p/elmah/

This will catch and log any unhandled errors, without your writing a line of code :)

刘备忘录 2022-11-22 14:02:58 5 楼

Since an exception occurred it means the page could not render (for whatever reason). This will cause an exception to propogate up the call stack until it is handled somewhere. The last place you can handle an exception in ASP.NET is within global.asax and since there was a problem you can create whatever output you want to be written to the client:

protected void Application_Error(Object sender, EventArgs e)
{
  Response.Write("Really sorry this happened")
}

This method will ensure all (unhandled) exceptions will be caught and treated in this way, so you'll also likely want to implement some kind of logging system here too.

Of course you can also specify a custom error page in the web.config.

白首有我共你 2022-11-22 14:02:58 4 楼

I use Application_Error to log the error and then do a Server.Transfer to a custom error page. By doing it this way I can grab the exception on that page and decide how to display it. I worry though that if you are wanting to show the exception in an alert that you may be using exceptions for the wrong purpose. You aren't throwing exceptions for validation errors or something else that can be anticipated, are you?

格子衫的從容 2022-11-22 14:02:58 3 楼

I believe that not try/catching exceptions at all could restrict you from some benefits/techniques like Repeating a function in C# until it no longer throws an exception. Anyway you can allow show custom error page on web.config if it fits.

I would personally use Application_Error in order to log that exceptions, but in this sense, better would be giving @MoXplod advice a try.

Btw, I might not be totally correct but writing the stacktrace to a page when an error occurs could consist of a security issue.

清风无影 2022-11-22 14:02:58 2 楼

The only real way to properly handle exceptions is to do so as close as possible to the offending code. This way you have much better control over how it should be best handled. In other words, having those try-catch statements "all over the code".

Take, for example this bit of code:

Int32 value = 0; // let's say this was passed in.
double newValue = 5 / value;

Is it better to alert the user that a problem occurred or is it better to have a fall back plan, for example, just assigning 0 to newValue? Your answer may change depending on the situation; however, if you are dealing with this in a generic way you artificially limit yourself.

千と千尋 2022-11-22 14:02:58 1 楼

In my case I ended up using Post Sharp, an AOP framework. I used it to enter some policy when exception occured.

Another option is Enterprise Library's policy injection, which allows code insertion in particular cases, such as - methods or classes surrounded by an attribute, and an Exception Handling Module attached to it.

This way or another, the solution for catching exception in an "abstract" (so to speak) level without filling the code with try-catch will probaby contain this amount of AOP.

goodluck

~没有更多了~
原文
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击“接受”或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。