什么是处理异常如何处理他们在asp.net的最佳途径， [英] What's the best way to handle the exceptions and how to deal with them in asp.net

问题描述

首先，我已经熟悉了简单的异常处理的语法，但我问的是最好的地方，最好的时间，对付他们的最好方法。

我要建一个N分层应用。所以我觉得DAL有时会产生一些错误处理..和我刚刚了解SQLException类，这是怎么回事与这门课吗？我曾经看到一个code处理SQLException的那么处理异常！

知道的做法，我要去哪里来处理它们后，我打算创建一个方法来连接到数据库和日志的错误在数据库中，所以我可以修复它​​但我仍然不知道是什么我收集的信息让我确定了整个局面！

---

我觉得异常处理是不是一个大问题。但每一个现在，然后我读了一些奇怪的建议 - 即我从来没有understood-对问题的意见，但没有一个人能回答我，因为这是一些很老的问题！

  

不要只捉明确
  例外

  
  

的code所使用的
  更高层次的应用程序必须
  永远只抛出异常，从不
  担心如何对付他们。

修改

什么 Page_Error事件事件和的Application_Error ..我看到他们是如何处理错误<一个很好的做法/ p>

解决方案

异常处理是一个大问题，这不是简单的设计应该是一个很好的策略。

首先，一些通用规则：

• 当运行code是发生异常的完全无法先走，所以也许它试图处理一些内部异常，但最终以失败告终。想想TCP连接：​​如果损坏的数据包到达时，这是一个例外，但TCP协议可以处理它。如果太多损坏，一个I / O或插座抛出异常


• 例外不可能永远的处理的。在几乎所有情况下，当你从下面的层异常，你是无法运行的纠正code。如果你的应用程序依赖于数据库，并处于脱机状态，当你得到关于它的例外，你只能显示一条错误消息


• 例外可能是意想不到的，并且可以揭示设计或实现缺陷。例如，实施缺陷可以在其中具有冗余数据库的情况，但是当你无法连接到弗里斯特镜子你不与第二
尝试

有关第三点，它发现任何奇怪的情况是为登录的异常，并定期分析日志重要的。所以，让我们用具体的答案开始。

首先

想处理的例外。当你写的每一个code线，想想可能无法完成prevent它，和想想可能的纠正措施可能出现的问题。如果有任何可能的。错误消息是不是一个很好的处理方式，它是最新的策略。

不要一开始写的try-catch（异常），但preFER特殊情况例外。如果您需要解析字符串编号等，然后期待 FormatException ，如果你需要从投对象你的类型期待 InvalidCastException的

当你写低层层

不要犹豫，抛出异常！不要做像很多人做的，即。 返回NULL 或使用（如ANSI C）一个布尔返回值和参考参数。例外的是那里的。如果你能处理异常（即你没有找到一个本地文件，但你知道你有一个远程备份，所以通过调用远程镜像处理 FileNotFoundException异常，但如果您无法连接还是最终再丢），那么这样做，并尝试恢复计算，但如果你不能再扔。而且不要忘了扔内部异常，如果present，因为它是在最高层记录有帮助的。

基本上，你仍然可以决定抛出自己的异常，即使你不抓住任何一个！这是强烈建议特别是当函数参数是无效的！

另一个很好的选择是仍然登录下面的层。实际上，你想记录无论发生异常。

当您登录

记得给适当的严重程度的消息。如果通过code，你的数据库脱机发现，这不是意外的异常。还是将其记录为一个错误，但是当你调查日志不用担心code错误。相反，如果赶上一个例外，你的code是无法识别（A 的NullReferenceException 是一个典型的例子），然后登录与最高严重性，即得。致命的，给它最高的优先级！

一个好的策略为ASP.NET

，当然可以在 Page.OnError 方法为主。如果您对您网站的所有页面的基页类，你一定要覆盖该方法。在该方法中，你首先应该的登录您的例外。

您也不能滥用的try-catch（异常）块，因为如果你不抓住你不能捕捉处理异常，您会必须通过的OnError处理它

当您运行这样的方法，不要马上去想 Server.RemoveError（）。您可以preFER有对HTTP 500错误静态HTML页面（当未处理的异常冒泡到ASP.NET运行时被触发）显示礼节信息给用户。

简单

1. 请不要犹豫，扔在基础层，如果有什么奇怪的发生


2. 如说你的意见，不要处理异常你不能处理（如果你发现你不能处理异常，重新抛出）


3. 日志!!!!!!!!!!!!!!!!!


4. 请不要在公共网站上公布异常的详细信息到最终用户，从来没有！默认情况下，ASP.NET prevents的发生，但你仍然可以使用的OnError打印堆栈跟踪


5. 使用的OnError 或的Application_Error 为单中心点，以处理所有的意外的异常


6. 定期检查对错误/致命消息日志以查找问题与code，再想想维护/调试/修复它

First, I'm already familiar with the simple exception handling syntax but I'm asking about the best place, the best time and the best way to deal with them.

I'm building an N-Layered application. so I think the DAL will sometime generate some errors to handle .. and I just learned about the SqlException class, what's the deal with that class ? I once saw a code that handles the SqlException then it handles Exception!

After knowing the practice and where I'm going to handle them, I'm planning to create a method to connect to the database and log the errors in a database so I could fix it but still I don't know what information should I collect to allow me identify the whole situation!

---

I thought exceptions handling was not a big deal. but every now and then I read some strange advices -that I never understood- on the questions comments but no one could answer me since it was some very old questions!

"Don't just explicitly catch exceptions"

"the code that is used by higher-layers in your application must always only throw exceptions and never worry about how to deal with them."

EDIT

What about Page_Error event and Application_Error .. I saw that they are a good practice for handling errors

解决方案

Exception handling is a big deal, and it's not simple to design a good strategy for that.

First of all, some general rules:

• Exceptions occur when the running code is completely unable to go ahead, so maybe it tried to handle some internal exceptions but ultimately failed. Think about TCP connection: if a damaged packet arrives, it's an exception, but TCP protocol can handle it. If too many are damaged, an I/O or socket exception is thrown
• Exceptions can not always be handled. In almost all cases, when you get an exception from underlying layers you are unable to run corrective code. If your application depends on a DB and that is offline, when you get the exception about it you can only display an error message
• Exceptions can be unexpected, and can reveal design or implementation flaws. For example, an implementation flaw can be the situation in which you have a redundant DB but when you fail to connect to frist mirror you don't try with the second

For the third point, it's important to log exceptions and periodically analyse logs to find any weird situation. So, let's begin with the concrete answer.

First of all

think about "handling" the exception. When you write every single code line, think about the possible problems that may prevent it from completing, and think about the possible corrective actions. if any are possible. An error message is not a good handling way, it's the latest strategy.

Don't start to write try-catch(Exception), but prefer specific exceptions. If you need to parse strings to numbers etc, then expect FormatException, if you need to cast from Object to your type expect InvalidCastException

When you write lower-level layers

don't hesitate to throw exceptions!! Don't do like many folks do, ie. return null or use (like ANSI C) a boolean return value and reference parameters. Exceptions are there for that. If you can handle an exception (ie. you don't find a local file but you know you have a remote backup, so handle FileNotFoundException by calling the remote mirror, but if you can't still connect then ultimately throw) then do it and try to resume computation, but if you cannot then throw. And don't forget to throw the inner exception, if present, because it is helpful for logging in the highest layer.

Basically, you can still decide to throw an exception on your own even if you don't catch any! And this is highly recommended especially when function parameters are invalid!

Another good option is to still log in the underlying layers. You actually want to log no matter an exception occurs.

When you log

remember to give an adequate severity to the messages. If you find via code that your DB is offline, that's not an unexpected exception. Still log it as an error, but don't worry about code bugs when you investigate the logs. Instead, if you catch an exception that your code is unable to recognize (a NullReferenceException is a classic example) then log with highest severity, ie. fatal, to give it maximum priority!

A good strategy for ASP.NET

can surely be based upon Page.OnError method. If you have a base page class for all of the pages of your site, you should definitely override that method. In that method, you should first log your exception.

You also shouldn't abuse of try-catch(Exception) blocks, because if you don't catch an exception you can't handle with catch, you will have to handle it via OnError.

When you run such a method, don't immediately think about Server.RemoveError(). You can prefer to have a static HTML page for HTTP 500 error (that is triggered when an unhandled exception bubbles to ASP.NET runtime) that displays a courtesy message to the user.

Briefly

1. Don't hesitate to throw in underlying layers if anything strange occurs
2. As said by your advice, don't handle exceptions you are unable to handle (if you catch an exception you can't handle, rethrow it)
3. LOG!!!!!!!!!!!!!!!!!
4. Don't disclose exception details to final users on a public website, never!! By default, ASP.NET prevents that from occurring, but you could still use OnError to print stack trace
5. Use OnError, or Application_Error as single central point to handle all unexpected exceptions
6. Periodically examine logs against error/fatal messages to find issues with your code, then think about maintaining/debugging/fixing it

这篇关于什么是处理异常如何处理他们在asp.net的最佳途径，的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！