在寻求实施最佳自定义错误处理实践的过程中,我想到了一个不使用try catch代码的想法。相反,我决定使用customErrors mode =“ On”并重定向到错误页面,并在此页面中显示异常详细信息。
//My test code from which error will come
public ActionResult Index()
{
AAA aa = null;
aa.a = "a";
}
//My web.config file
<customErrors mode="On" defaultRedirect="~/Errors/Error.aspx">
<error statusCode="404" redirect="~/Errors/404.html" />
</customErrors>
//My error handling page(Error.aspx):
protected void Page_Load(object sender, EventArgs e)
{
Exception error;
error = Server.GetLastError();
}
我相信我应该在我的错误处理页面中收到错误消息。但是我总是空的。
如何在错误处理页面中获取异常消息?
答案 0 :(得分:0)
让我了解一下我通常在工作的项目中如何处理异常。但是,让我们分为几部分。
错误页面在生产环境中不应显示真正的异常。用户无需知道数据库发生了故障,而这可能会使您的系统面临安全问题。具有一般性错误或有据可查的错误代码的页面可以胜任。
但是,当然,在您的开发环境中,可以显示异常。我建议在这种情况下使用customErrors mode="RemoteOnly"
。
根据正在开发的系统,在消息中包含错误代码非常重要。例如,用户可以看到“无法连接(XYZ_1234)” 或“无法连接(ABC_9876)” -相同的消息,不同的代码-并将其发送到支持团队。如果支持团队有一个与代码匹配的文档,但有真正的例外,他们将能够向开发人员发送适当的报告。
尝试/捕捉是您遇到异常时最好的朋友。尤其是因为它会在必要时帮助您自定义异常。您可能有一系列自定义异常类-每个异常类都有自己的特征-即使在调试之前,它们也可以帮助您了解问题。一个简单的例子:
public class ExceptionWithCode : Exception
{
public ExceptionWithCode(string code, string message) : base(message)
{
this.Code = code;
}
public string Code { get; }
}
在代码中,您应该以这种方式或多或少地使用它:
try
{
// Do whatever database operation here
}
catch (SqlException ex)
{
// Log the exception
_logService.Log(ex);
// Throw something else to the user
throw new ExceptionWithCode("XYZ_1234", "Unable to connect");
}
catch (Exception ex)
{
// Log the exception
_logService.Log(ex);
// Throw something else to the user
throw new ExceptionWithCode("ABC_9876", "Unable to connect");
}
请注意,我正在使用2个鱼钩。第一个是因为我知道可能会发生这种异常,因为我正在连接到数据库,第二个是万一可能发生其他任何事情。此外,用户不知道真正的异常,因为他/她只是获得代码的随机异常而不是数据库连接失败。
这是非常重要的部分。请记住:永远不要向用户显示真实的异常。相反,请将它们记录在易于访问的位置。这可能在服务器,数据库甚至Windows事件日志中的文件中。您不一定需要编写自己的日志记录工具,您可以使用Internet上可用的任何内容。我最喜欢的是SeriLog,因为我将大多数事件/异常记录在文本文件中。但是我在{.3 Framework}中使用了ELMAH已有相当长的时间了,它对于XML格式的日志非常有用。
这对我有用,因为: