Question

我的问题是弹簧重试。假设一个简单的示例代码，其中我有一个Service层和Controller类。，

这是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位于Service界面中。但是我还没有实现@Recover方法。我的想法是因为我真的没有任何辅助数据库，如果数据库已关闭，那么恢复选项确实没有添加@Recovery方法。而是在控制器中捕获并处理了异常。

我的问题是：

上述方法是否错误。如果是这样，如何以正确的方式做到这一点？
是否始终需要恢复方法？如果是这样的话，在这种情况下恢复将会是什么样的情况，例如数据库正在关闭而没有其他数据源。
在控制器和句柄中捕获异常是错误的他们呢？（有人告诉我，服务人员应该处理所有问题一些讨论中的例外情况。）

我所看到的每个地方都是某种恢复方法，但如果有这种情况，就无法找到适合此类情况的适当恢复处理程序的可靠示例。

Answer 1

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

没有@Recovery并且通过你喜欢的任何方式处理调用者中的异常是完全正常的。

Answer 2

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

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

使用Spring-Retry时是否需要@Recovery方法？

2 个答案: