我发现了如何处理ASP.NET中的意外错误(使用Page_Error和Application_Error方法以及Web中的customErrors指令)的大量信息(即this)。配置。在ASP.NET中向用户显示预期的错误
但是,我的问题是处理预期错误的最佳方法是什么。例如,我有一个页面来显示记录。每条记录都有一个允许查看的用户的特定列表。由于许多用户可能具有不在所述列表上的“查看记录”角色,因此我必须在页面上编写一些代码来对其进行过滤。
protected void Page_Load(object sender, EventArgs e)
{
var user = Membership.GetUser();
if (!CanUserViewThisRecord(Request["id"], user.Username)
{
// Display an error to the user that says,
// "You are not allowed to view this message", and quit.
}
else
{
// Display the page.
}
}
处理这类错误的最佳做法是什么?我可以想到几种可能性:
- 重定向到错误页面。
- 在每个名为“lblErrorText”的页面上放置一个标签。除非出现错误,否则保持空白。
- 引发异常并让标准错误处理处理它。
这感觉就像是一个基本问题,为此我表示歉意,但几乎所有我发现的内容都引用了意外的例外。这并不是说上述任何一种可能性都很难实现,但如果可能的话,我想使用标准的推荐方法。
注意:谢谢大家的答案。我想澄清一下,用户将无法点击允许查看的记录链接。这个问题更多的是为了防守。例如,由于记录ID在URL中,所以有人可能会在地址栏中输入禁止记录的ID。或者被允许的用户A可以通过电子邮件发送到不是用户B的链接。看来我可能不会正确地使用“例外”和“错误”这两个词,但希望这种情况是有道理的。
用户永远不会看到他们不允许查看的页面的链接,但该记录的ID在URL中。我试图阻止某人可能会手动修改URL以包含不允许的记录ID的情况。这是我在这里处理的情况。我想我可以做的就是尝试在母版页上放置一个“错误文本”控件,这样我就不必修改每一页来完成这项工作。 – Mike 2011-02-14 15:33:55
+1用于防止错误评论。如果预计你应该已经做了一些事情,那么'预期错误'有点矛盾。恕我直言,手动更改URL但不是预期的。我会认为这是一个例外,与您在URL中输入不存在的ID的用户一样。 – 2011-02-14 15:34:48