Question

我在Web.config中使用Page_Error和Application_Error方法以及customErrors指令找到了大量关于如何处理ASP.NET中意外错误的信息（即this。

但是，我的问题是处理EXPECTED错误的最佳方法是什么。例如，我有一个页面来显示记录。每条记录都有一个允许查看它的特定用户列表。由于许多用户可能具有不在列表中的“查看记录”角色，因此我必须在页面上编写一些代码来过滤它们。

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的链接。似乎我可能没有以正确的方式使用“异常”和“错误”这两个词，但希望这种情况有意义。

Answer 1

为了优雅地失败，我会选择在页面上显示一条消息。

更好的是防止错误;如果您提前知道用户将无法在页面上执行任何操作，请不要提供指向该页面的链接。通常，用户应该只看到他们可以做的事情。

Answer 2

正如其他人所提到的，我希望在发送之前阻止它，或者通过禁用这些用户的功能，或者在发送页面之前用javascript捕获它。

您仍然需要检查服务器上是否允许用户使用控件，在这种情况下，建议的标签最好作为其他3个解决方案的解决方案。

然而，另一个解决方案是为页面提供一个隐藏值，该页面由页面内的javascript检查，生成警报或更容易发现的错误对话，而不是可能错过的标签，导致混淆为什么没有发生。

根据提问者的评论进行编辑：如果修改URL中的数字是指向用户未经授权使用的记录所需的全部内容，POST可能是比GET更好的使用方法吗？这样处理此错误的方式就不那么重要了，因为没有标准用户会遇到它。

Answer 3

在你的三个选项中，第三个选项是我最不喜欢的。用户尝试查看您告诉他的记录并不是一个例外。重定向到错误页面更合理，错误标签也是如此。但是，它们都不是特别方便用户。

我不知道您的UI是如何构建的，但在我看来，如果您知道不允许用户查看记录，则不应让用户尝试查看记录。也就是说，如果您知道用户无法查看该记录，那么请不要让他有机会点击它。永远不要说到“你无法查看此记录。”

如果您无法阻止用户尝试查看记录，我认为弹出式消息框比前两个选项更适合。

Answer 4

在我看来，这个问题是更多的方法论，然后是技术..

我认为在导致错误的对象/操作附近显示错误消息更为正确。

如果你把他送到另一个页面，他将失去方向，不清楚导致这个错误的原因。

所以我认为将错误信息放在同一页面更为正确。也许给他机会纠正..

在ASP.NET中向用户显示预期错误

4 个答案: