ASP.NET HttpRequest 可以为 null 吗？ CurrentExecutionFilePath 怎么样？
我们在生产服务器中遇到了一个奇怪的错误。 我们有堆栈跟踪，但没有行号，所以我知道错误所在的方法，但不知道确切的行。 它抱怨“对象引用未设置到对象的实例”。 有些东西是空的。
查看代码后，我能看到的唯一两个潜在的罪魁祸首是连续两行：
string currentPath = this.Request.CurrentExecutionFilePath;
string[] parts = currentPath.Split('/');
如果 Request 为 null，或者如果 Request 的 CurrentExecutionFilePath 为 null，则会抛出异常。 我不太清楚什么时候（或者是否）会发生这种情况。 我是不是找错树了？ （此代码似乎在页面生命周期的加载部分运行）。
We're getting an odd bug in a production server. We have a stack trace, but no line numbers, so I know the method where the bug is, but not the exact line. It's complaining of a "Object reference not set to an instance of an object." Something is null.
After looking at the code, the only two potential culprits that I can see are the two consecutive lines that read:
string currentPath = this.Request.CurrentExecutionFilePath;
string[] parts = currentPath.Split('/');
which would throw if Request was null, or if the CurrentExecutionFilePath of the Request was null. I'm not really clear on when (or even if) this can happen. Am I barking up the wrong tree here? (This code seems to be running during the Load portion of the page lifecycle).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您从第一个线程启动线程，则请求和/或 HttpContext 可以为 null。 （异步处理等）
The request and/or HttpContext can be null if you launch threads from your first one. (Asynchronous processing, etc.)
您是否为您的发布版本启用了 PDB 输出？
如果这样做，您只需将 pdb 部署到生产服务器即可获取堆栈跟踪中的行号。
（pdb和dll必须匹配）
Do you have PDB output enabled for your release build?
If you do you would only need to deploy the pdb to your production server to get line numbers in your stack trace.
(pdb and dlls have to match)
奇怪的是，我在生产服务器上多次看到 null HttpRequest 错误，但始终无法找出原因。
我知道这对你没有任何用处，但我只是出于团结而写下:)
我记得的一件可能的事情是 IIS 没有将根映射到 /Default.aspx，但同样，这都是很久以前的事了，所以请不要过多关注这些可能无用的闲言碎语！
Oddly enough I have seen a null HttpRequest error (many many) times on a production server without ever being able to find out the cause.
I know that is of no use to you whatsoever but am just writing out of solidarity :)
One potential thing that I half remember was to do with IIS not mapping the root to /Default.aspx but again, this was all long ago so please don't pay too much attention to these potentialy unhelpful ramblings!!!