GraphQL-Java 中空错误位置引发的序列化异常问题解析

问题背景

在 GraphQL-Java 项目中，当解析无效的 GraphQL 模式定义语言(SDL)时，SchemaGenerator 会抛出 SchemaProblem 异常。这个异常包含了一系列 GraphQLError 对象，用于描述模式定义中的具体问题。然而，在某些情况下，这些错误对象可能包含空(null)的源位置信息，导致后续的序列化操作抛出空指针异常(NPE)。

问题重现

考虑以下场景：开发者尝试解析一个包含联邦制(federation)扩展的 GraphQL 模式，但其中可能存在某些语法或语义错误。当 SchemaGenerator 处理这个模式时，会生成包含错误信息的 SchemaProblem 异常。如果尝试将这些错误信息序列化为规范格式(通过调用 toSpecification() 方法)，就会遇到空指针异常。

技术分析

问题的核心在于 BaseError 类的 getLocations() 方法实现。当错误节点(node)的源位置(source location)为 null 时，该方法仍然会尝试将这个 null 值包含在返回的位置列表中。而后续的序列化过程(GraphQLErrorHelper.location() 方法)则假设所有位置信息都是非空的 SourceLocation 对象，直接调用了 getLine() 和 getColumn() 方法，导致了空指针异常。

解决方案

项目维护者提供了两种可能的修复方案：

1. 在源头过滤：修改 BaseError.getLocations() 方法，在返回位置列表前先检查节点及其源位置是否为 null。如果发现 null 值，则返回一个默认的"无位置"标记(NO_WHERE)。

2. 在序列化层处理：修改 GraphQLErrorHelper.location() 方法，使其能够处理 null 值的 SourceLocation 参数。当遇到 null 时，直接返回 null 或者跳过该位置的序列化。

最终，项目采用了第二种方案，即在序列化层增加对 null 值的处理逻辑。这种方案的优势在于：

• 保持了错误信息的原始性，不改变错误收集阶段的逻辑
• 更符合防御性编程的原则，序列化方法应该能够处理各种边界情况
• 不会影响其他可能依赖原始错误位置信息的代码路径

技术启示

这个问题揭示了几个值得注意的编程实践：

1. 防御性编程：对于公共 API 方法，特别是那些可能被多种上下文调用的方法(如错误序列化)，应该考虑所有可能的输入情况，包括 null 值。

2. 错误处理的一致性：在构建错误处理系统时，应该确保从错误收集到错误展示的整个流程都能处理各种边界情况。

3. 不变式验证：对于像 SourceLocation 这样的值对象，可以考虑在构造函数中添加验证逻辑，确保创建的对象始终处于有效状态。

最佳实践建议

基于这个问题的经验，建议开发者在处理 GraphQL 模式验证时：

1. 总是对 SchemaProblem 异常中的错误信息进行防御性处理
2. 在自定义错误类型时，确保 getLocations() 方法返回的列表不包含 null 值
3. 考虑在模式验证阶段就捕获并处理可能导致后续序列化问题的错误情况

这个问题的修复不仅解决了直接的异常问题，也提高了整个库在错误处理方面的健壮性，为开发者提供了更可靠的使用体验。