“java.lang.NullPointerException”的最常见原因是 处理 XML 时？
我最强的线索是，处理传入 XML 的代码实际上接收到了无效/不完整的文件，因此 DOM 解析失败。 有什么建议么？
My strongest lead is that the code who deals with the incoming XMLs is actually receiving an invalid/incomplete file hence failing the DOM parsing. Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不完整的文件绝对是开始寻找的地方。 我会在解析文件之前打印出该文件，以查看发送到解析器的内容。 如果不完整，那就很明显了。 如果它无效，您将需要进行一些搜索。
Incomplete file is definitely the place to start looking. I'd print out the file right before the point you parse it to see what's getting sent to the parser. If it's incomplete it will be obvious. If it's invalid, you'll have a little searching to do.
您应该有一个堆栈跟踪指向抛出 NPE 的位置。 这应该会缩小可以为空的变量的数量。 我建议添加适当的检查并在检测到错误后立即抛出异常，而不是让调试器或 printf 退出。 这是一个好习惯，可以避免以后出现神秘的问题。
You should have a stack trace pointing to where you NPE is thrown. That should narrow down the number of variables that can be null. Rather than getting the debugger or printf out, I suggest adding appropriate checks and throwing an exception where as soon as the error can be detected. It's a good habit to get into to avoid mysterious problems later.
我的第一个猜测是，使用 DOM 的代码将 DTD 中标记为可选的元素视为强制元素。
编辑添加：
我的意思是，除非您针对 DTD 进行验证，否则您不能期望像下面这样的内容（使用 dom4j 的示例）返回除 null 之外的任何内容。
如果您将元素导航调用串联在一起，或者通常在使用返回值之前不检查返回值，情况当然也是如此。
My first guess would be that the DOM-using code is treating elements that are marked as optional in the DTD as compulsory.
Edited to add:
What I mean is that unless you validate against a DTD, you cannot expect something like the following (example using dom4j) to return anything but null.
The same is of course true if you're stringing element navigation calls together, or generally don't check return values before using them.
理想情况下，您应该在调试器中运行您的 java 应用程序，因此当引发未捕获的异常时，您可以检查调用堆栈、变量等，并准确查看哪一行导致了崩溃，以及可能使用了哪些数据为 null。
如果出于某种原因无法使用调试器，请使用调试支持编译应用程序，并为该特定错误添加异常处理程序，并打印出堆栈跟踪。 同样，这将准确显示哪个文件中的哪一行导致了崩溃。
Ideally you should be running your java application inside a debugger, thus when an uncaught exception is thrown you can examine the callstack, variables, etc and see exactly what line caused the crash, and perhaps which data is null that got used.
If you can't use a debugger for whatever reason, then compile your application with debugging support, and add an exception handler for this particular error, and print out the stack trace. Again, this will show exactly what line in what file caused the crash.