如果缺少必需的querystring参数并且让global.asax用Application_Error捕获它，那么让asp.net页面抛出（自定义错误）是否有什么问题，然后将用户转移到错误页面？我有几个基类来执行这些检查，我不确定将错误传达给用户的最佳方法。
所以，像这样：
int reqParam;
if(!isParamSet("myReqParam", out reqParam))
{
throw new QuerystringParamMissingException();
}
然后由global.asax中的Application_Error捕获。
另外，从安全角度来看，我应该向用户提供多少信息？只是它是一个错误，或者缺少一个查询字符串参数，或者哪个参数丢失了，甚至可能是该参数指示用于什么？
答案 0 :(得分：3)
这一切都取决于错误的严重程度以及用户是否可以轻松地从错误中恢复。
一种观点是用户不应该进行无效调用 - 所有需要查询字符串的链接都应该在客户端验证，因此在网站正常运行期间，所有查询都会完整且有效。因此，如果缺少参数，那将是一个严重的错误，因此提出异常是一种非常有效的方法。
如果您想阻止人们修改查询字符串以访问他们不应该访问的系统部分，那将非常有用。他们可能会错过参数并显示自定义错误页面可能不会给他们任何关于他们出错的线索。
你应该记录错误 - 所以至少你知道错误的地方和地点。
答案 1 :(得分：2)
只要你不相信在正常的应用程序使用中出现这种情况，这是一个可以接受的解决方案。
通过让异常冒泡到堆栈中的任何操作都可以从错误中恢复，在这种情况下，您可能无法恢复。
答案 2 :(得分：0)
我相信只要您能够控制情况，就不应该让您的应用程序抛出错误。我的意思是，因为你知道什么参数可能会丢失...所以你可以提示用户，而不是抛出错误，然后让应用程序处理其余的情况。
而是提供用户友好的消息，并帮助用户了解出了什么问题！
谢谢， 小心。
答案 3 :(得分：0)
您应该记录由用户手动操作查询字符串然后重定向到默认页面（主页或登录页面）导致的（您必须确定）此错误。 缺少的参数是由您的应用程序引起的。没有完全验证用户输入，那么你应该消除原因。
答案 4 :(得分：-1)
请记住抛出异常会产生性能成本。只需将页面重定向到错误页面＆amp;处理错误而不抛出异常。
话虽如此， 只是抛出异常相当方便，因为ASP.NET中有很多可配置和内置的机制来处理异常，例如： / p>
HttpContext.Error
HttpContext.AllErrors
HttpContext.IsCustomErrorEnabled
<customErrors defaultRedirect="..."> node in the web.config