1

我的问题是关于春季重试。假设我有一个简单的示例代码，其中我有一个服务层和控制器类。，

这是 testService 接口

public interface testService{
   @Retryable(value = { KnownExceptiomn.class }, backoff = @Backoff(delay = 1000), maxAttempts = 2)
   Address getAddress(String emailAddress);
}

这是服务的实现

public class testServiceImpl{
public Address getAddress(String emailAddress){
   //addressRepository is a crud repository
   return addressRepository.getAddressFromEmail(emailAddress);
   }
}

控制器是

    @GetMapping("path/{emailId}")
    public ResponseEntity<?> getAddress(@PathVariable("emailId") final String email){
      final Address address;
      try{
        address= testService.getAddress(String emailAddress);
        if(address != null) return new ResponseEntity<Address>(address,HttpStatus.OK);

        return new ResponseEntity<String>("Invalid Email", HttpStatus.BAD_REQUEST);
        }catch(KnownException e){
   return errorMessage("Error");
       }

}

正如所见，@Retryble 在服务接口中。但是我还没有实现@Recover 方法。我的想法是因为我真的没有任何辅助数据库，如果数据库已关闭，则确实没有恢复选项，我没有添加 @Recovery 方法。相反，异常被控制器捕获并处理。

我的问题是：

  1. 上述方法是否错误。如果是这样，如何以正确的方式做到这一点？
  2. 是否总是需要有恢复方法？如果是这样，在数据库关闭且没有其他数据来源的情况下，将如何恢复。

  3. 在控制器中捕获异常并相应地处理它们是错误的吗？（有人告诉我，服务人员应该处理一些讨论中的所有异常）。

    我所看到的任何地方都是某种恢复方法，但如果有的话，找不到具有适当恢复处理程序的可靠示例。

4

2 回答 2

1

@Recovery是可选的；如果没有，在重试用尽后，最后一个异常被抛出给调用者，调用者必须处理该异常。

@Recovery不管你喜欢什么方式，在调用者中没有和处理异常是完全正常的。

于 2018-04-12T13:13:11.523 回答
0

@Vipin Menon：我认为您指的是@Recover注释，所以答案是否定的。 @Recover提供注释只是为了让程序员灵活地创建恢复方法以在重试尝试也失败时返回默认（回退）响应。

简而言之，@Recover如果重试尝试失败时不需要任何默认行为，请不要使用注释创建恢复方法。只需@Retryable在实际服务方法上使用注释即可。

于 2021-07-25T15:07:12.237 回答