2012-03-19 130 views
0

在ASP中抛出异常(如“ArgumentException”)是个好主意吗?我红了一些文章,并且我知道抛出的异常转到Page_Error方法。在此之后,执行永久停留在这里。如何在Page_Error之后继续执行?C#/ ASP - 异常抛出

或者我应该不用扔,让这样的事情:

person.name = "blablabla"; 
if (person.NameValidatingError) Response.Write ("Ooops"); 
+0

如果没有人捕获它们,那么异常是毫无意义的 – BlackBear 2012-03-19 17:12:12

+0

什么是'.NameValidatingError'?它是在对象上设置的布尔值吗? – Origin 2012-03-19 17:12:30

+0

@up这只是一个例子。 – zgnilec 2012-03-19 17:14:06

回答

0

你应该有一个错误页面为您的整个应用程序,所有的例外转移到该页面。

+0

但我不想要1页的错误,我需要把错误信息内的HTML内容W/O重定向等。 – zgnilec 2012-03-19 17:15:26

1

如果您希望参数符合某种验证规则,并且传入的参数不符合它们(并且您无法恢复),那么最好抛出一个ArgumentException来解释为什么它被拒绝。

您应该在page_error然后重定向到错误页面。

0

而不是在设置某些东西后检查一个变量,如果知道它可能会引发错误,则将其封装在try/catch块中。

像这样:

try 
    person.name = "blablabla" 
catch ex as YourExceptionType 
    messagebox.show("There was an error in the foobar") 
end try 

... continue code here 
-1

如果该方法可以处理自己的错误,而无需把代码处于无效状态,那么就没有必要抛出异常。

否则,该方法应该抛出一个异常,留给调用者决定是否知道如何处理异常,或者保持未被捕获。

+0

downvote的任何理由? – mbeckish 2012-04-18 13:22:00

0

如果我们在谈论C#或Asp.Net并不重要,但问题是如果这是一个很好的做法抛出异常。 一般而言,只有在严格需要时才会抛出异常,因为异常抛出会导致性能下降(有时甚至会隐藏堆栈跟踪)。 另一个方面是,你可能无法预见的一个例外是,当你编写该功能,但不是你已经知道它可能发生/避免发生的事情 我建议你尽可能避免抛出异常,如果它在您的域中是必需的,您可以创建一个错误页面以在您每次收到非托管异常时重定向到该页面。