如何利用Optional.orElseThrow实战构建符合JSON-RPC风格的变量错误处理

在JSON-RPC 2.0协议里，参数校验这事儿，关键就两点：数据必须存在，格式必须合规。一旦出问题，就得返回个标准错误结构，比方说code=-32602，message是Invalid params那样。Ja va里Optional配合orElseThrow，恰好能把这类逻辑写得既简洁又声明式，省掉那些繁琐的null判断和if-else嵌套。

用Optional包装关键参数提取结果

JSON-RPC的请求体，一般会解析成Map或者DTO。对于method、params这类必填字段，提取之后直接封装成Optional就行。具体来说，用Map.get(key)拿到值，再调用Optional.ofNullable()，而不是逐行写判空逻辑。要是碰到嵌套结构，比如从params里取accountId，可以通过map()加flatMap()链式往下走，一路构建深层Optional。举个例子：Optional method = Optional.ofNullable(request.get("method")).map(Object::toString);——这样写，代码意图一目了然。

用orElseThrow抛出符合JSON-RPC错误码的异常

orElseThrow()这一步，是整个流程的关键。它抛出的可不是普通异常，而是带协议语义的异常。你需要先定义一个统一的异常基类，比如JsonRpcException，里边带上code（int）和message（String）这两个字段。然后为每种缺失场景准备静态工厂方法，比如JsonRpcException.missingParam("method")，返回code=-32602。使用时直接传入工厂方法引用：method.orElseThrow(() -> JsonRpcException.missingParam("method"));——简洁，而且语义清晰。

统一异常处理器映射到标准error结构

在Spring MVC或者自定义HTTP处理器里，捕获JsonRpcException然后生成合规的响应体。响应体必须包含jsonrpc、error（内含code和message）、id这几个字段。特别要留意的是，id得从原始请求里原封不动透传下来，哪怕它是null或者空字符串，也得照原样返回。还有一点，异常处理器里不要再抛新异常；所有校验失败的情况，都应该收敛到JsonRpcException及其子类里。

注意Optional的边界：不适用于类型转换失败

说到底，Optional只管“值是否存在”，管不了“值是否合法”。举个例子，请求里的id字段传了个"abc"，这明显不是数字字符串。正确的做法是：先用Optional.ofNullable(request.get("id"))确认这个key存在，然后通过map(Object::toString).filter(StringUtils::isNumeric).map(Long::parseLong)做类型和格式的联合校验。校验失败时，依然调用orElseThrow(JsonRpcException::invalidParam)，确保错误出口统一——这样一来，整个校验流程清晰、可维护，也严格遵循了JSON-RPC协议的要求。