16.3.1　发送错误信息到客户端

例如，我们为 SpittleController 添加一个新的处理器方法，它会提供单个 Spittle 对象：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public @ResponseBody Spittle spittleById(@PathVariable long id) {
  return spittleRepository.findOne(id);
}

在这里，通过 id 参数传入了一个 ID，然后根据它调用 Repository 的 findOne() 方法，查找 Spittle 对象。处理器方法会返回 findOne() 方法得到的 Spittle 对象，消息转换器会负责产生客户端所需的资源表述。

非常简单，对吧？我们没办法让它更棒了。它还能更好吗？

如果根据给定的 ID，无法找到某个 Spittle 对象的 ID 属性能够与之匹配，findOne() 方法返回 null 的时候，你觉得会发生什么呢？

结果就是 spittleById() 方法会返回 null，响应体为空，不会返回任何有用的数据给客户端。同时，响应中默认的 HTTP 状态码是 200（OK），表示所有的事情运行正常。

但是，所有的事情都是不对的。客户端要求 Spittle 对象，但是它什么都没有得到。它既没有收到 Spittle 对象也没有收到任何消息表明出现了错误。服务器实际上是在说：“这是一个没用的响应，但是能够告诉你一切都正常！”

现在，我们考虑一下在这种场景下应该发生什么。至少，状态码不应该是 200，而应该是 404（Not Found），告诉客户端它们所要求的内容没有找到。如果响应体中能够包含错误信息而不是空的话就更好了。

Spring 提供了多种方式来处理这样的场景：

使用 @ResponseStatus 注解可以指定状态码；
控制器方法可以返回 ResponseEntity 对象，该对象能够包含更多响应相关的元数据；
异常处理器能够应对错误场景，这样处理器方法就能关注于正常的状况。

在这个方面，Spring 提供了很多的灵活性，其实也不存在唯一正确的方式。我不会用某一种固定的策略来处理所有的错误或涵盖所有的场景，而是会向读者展现多种修改 spittleById() 的方法，以应对 Spittle 无法找到的场景。

使用 ResponseEntity

作为 @ResponseBody 的替代方案，控制器方法可以返回一个 ResponseEntity 对象。ResponseEntity 中可以包含响应相关的元数据（如头部信息和状态码）以及要转换成资源表述的对象。

因为 ResponseEntity 允许我们指定响应的状态码，所以当无法找到 Spittle 的时候，我们可以返回 HTTP 404 错误。如下是新版本的 spittleById()，它会返回 ResponseEntity：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public @ResponseBody Spittle spittleById(@PathVariable long id) {
  Spittle spittle = spittleRepository.findOne(id);
  HttpStatus status = spittle != null ? HttpStatus.OK : HttpStatus.NOT_FOUND;
  return new ResponseEntity<Spittle>(spittle, status);
}

像前面一样，路径中得到的 ID 用来从 Repository 中检索 Spittle。如果找到的话，状态码设置为 HttpStatus.OK（这是之前的默认值），但是如果 Repository 返回 null 的话，状态码设置为 HttpStatus.NOT_FOUND，这会转换为 HTTP 404。最后，会创建一个新的 ResponseEntity，它会把 Spittle 和状态码传送给客户端。

注意这个 spittleById() 方法没有使用 @ResponseBody 注解。除了包含响应头信息、状态码以及负载以外，ResponseEntity 还包含了 @ResponseBody 的语义，因此负载部分将会渲染到响应体中，就像之前在方法上使用 @ResponseBody 注解一样。如果返回 ResponseEntity 的话，那就没有必要在方法上使用 @ResponseBody 注解了。

我们在正确的方向上走出了第一步，如果所要求的 Spittle 无法找到的话，客户端能够得到一个合适的状态码。但是在本例中，响应体依然为空。我们可能会希望在响应体中包含一些错误信息。

我们重试一次，首先定义一个包含错误信息的 Error 对象：

public Error {
  private int code;
  private String message;
  
  public Error(int code, String message) {
    this.code = code;
    this.message = message;
  }
  
  public int getCode() {
    return code;
  }
  
  public int getMessage() {
    return message;
  }
}

然后，我们可以修改 spittleById()，让它返回 Error：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public ResponseEntity<?> spittleById(@PathVariable long id) {
  Spittle spittle = spittleRepository.findOne(id);
  if (spittle == null) {
    Error error = new Error(4, "Spittle [" + id + "] not found");
    return new ResponseEntity<Error>(error, HttpStatus.NOT_FOUND);
  }
  return new ResponseEntity<Spittle>(spittle, HttpStatus.OK);
}

现在，这个方法的行为已经符合我们的预期了。如果找到 Spittle 的话，就会把返回的对象以及 200（OK）的状态码封装到 ResponseEntity 中。另一方面，如果 findOne() 返回 null 的话，将会创建一个 Error 对象，并将其与 404（Not Found）状态码一起封装到 ResponseEntity 中，然后返回。

你也许觉得我们可以到此结束这个话题了。毕竟，方法按照我们期望的方式在运行。但是，还有一点事情让我不太舒服。

首先，这比我们开始的时候更为复杂。涉及到了更多的逻辑，包括条件语句。另外，方法返回 ResponseEntity<?> 感觉有些问题。ResponseEntity 所使用的泛型为它的解析或出现错误留下了太多的空间。

不过，我们可以借助错误处理器来修正这些问题。

处理错误

spittleById() 方法中的 if 代码块是处理错误的，但这是控制器中错误处理器（error handler）所擅长的领域。错误处理器能够处理导致问题的场景，这样常规的处理器方法就能只关心正常的逻辑处理路径了。

我们重构一下代码来使用错误处理器。首先，定义能够对应 SpittleNotFoundException 的错误处理器：

@ExceptionHandler(SpittleNotFoundException.class)
@ResponseStatus(HttpStatus.NOT_FOUND)
public @ResponseBody Error spittleNotFound(SpittleNotFoundException e) {
  long spittleId = e.getSpittleId();
  return new Error(4, "Spittle [" + spittleId + "] not found");
}

@ExceptionHandler 注解能够用到控制器方法中，用来处理特定的异常。这里，它表明如果在控制器的任意处理方法中抛出 SpittleNotFoundException 异常，就会调用 spittleNotFound() 方法来处理异常。

至于 SpittleNotFoundException，它是一个很简单异常类：

package spittr.data;

public class SpittleNotFoundException extends RuntimeException {

  private static final long serialVersionUID = 1L;
  
  private long spittleId;

  public SpittleNotFoundException(long spittleId) {
    this.spittleId = spittleId;
  }
  
  public long getSpittleId() {
    return spittleId;
  }
  
}

现在，我们可以移除掉 spittleById() 方法中大多数的错误处理代码：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public ResponseEntity<Spittle> spittleById(@PathVariable long id) {
  Spittle spittle = spittleRepository.findOne(id);
  if (spittle == null) { throw new SpittleNotFoundException(id); }
  return new ResponseEntity<Spittle>(spittle, HttpStatus.OK);
}

这个版本的 spittleById() 方法确实干净了很多。除了对返回值进行 null 检查，它完全关注于成功的场景，也就是能够找到请求的 Spittle。同时，在返回类型中，我们能移除掉奇怪的泛型了。

不过，我们能够让代码更加干净一些。现在我们已经知道 spittleById() 将会返回 Spittle 并且 HTTP 状态码始终会是 200（OK），那么就可以不再使用 ResponseEntity，而是将其替换为 @ResponseBody：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public @ResponseBody Spittle spittleById(@PathVariable long id) {
  Spittle spittle = spittleRepository.findOne(id);
  if (spittle == null) { throw new SpittleNotFoundException(id); }
  return spittle;
}

当然，如果控制器类上使用了 @RestController，我们甚至不再需要 @ResponseBody：

@RequestMapping(value="/{id}", method=RequestMethod.GET)
public Spittle spittleById(@PathVariable long id) {
  Spittle spittle = spittleRepository.findOne(id);
  if (spittle == null) { throw new SpittleNotFoundException(id); }
  return spittle;
}

鉴于错误处理器的方法会始终返回 Error，并且 HTTP 状态码为 404（Not Found），那么现在我们可以对 spittleNotFound() 方法进行类似的清理：

@ExceptionHandler(SpittleNotFoundException.class)
@ResponseStatus(HttpStatus.NOT_FOUND)
public @ResponseBody Error spittleNotFound(SpittleNotFoundException e) {
  long spittleId = e.getSpittleId();
  return new Error(4, "Spittle [" + spittleId + "] not found");
}

因为 spittleNotFound() 方法始终会返回 Error，所以使用 ResponseEntity 的唯一原因就是能够设置状态码。但是通过为 spittleNotFound() 方法添加 @ResponseStatus(HttpStatus.NOT_FOUND) 注解，我们可以达到相同的效果，而且可以不再使用 ResponseEntity 了。

同样，如果控制器类上使用了 @RestController，那么就可以移除掉 @ResponseBody，让代码更加干净：

@ExceptionHandler(SpittleNotFoundException.class)
@ResponseStatus(HttpStatus.NOT_FOUND)
public Error spittleNotFound(SpittleNotFoundException e) {
  long spittleId = e.getSpittleId();
  return new Error(4, "Spittle [" + spittleId + "] not found");
}

在一定程度上，我们已经圆满达到了想要的效果。为了设置响应状态码，我们首先使用 ResponseEntity，但是稍后我们借助异常处理器以及 @ResponseStatus，避免使用 ResponseEntity，从而让代码更加整洁。

似乎，我们不再需要使用 ResponseEntity 了。但是，有一种场景 ResponseEntity 能够很好地完成，但是其他的注解或异常处理器却做不到。现在，我们看一下如何在响应中设置头部信息。

Previous16.3　提供资源之外的其他内容 Next16.3.2　在响应中设置头部信息

Last updated 5 years ago