Which way is better for handling exception from the sub-project (provider)

user_1773011 0
Viewed 52

I have a microservice. It has a controller calling its sub-project (provider). So the controller depends on the provider.

The provider is using grpc to call another service. The provider knows the service it calls, but the controller doesn't. (I do this way to follow the basic design pattern of de-coupling).

Right now, the problem is: the service which the provider calls throws iServiceException. But only the controller knows how to handle the exception.

Method 1: Since we cannot just rethrow the iServiceException from the provider (Because the controller doesn't know iServiceException and cannot catch it), we can just rethrow the standard java Exception, then the controller can catch it. But my concern here is: is this a good way to do? Since Exception contains less information than iServiceException.

Method 2: Implement another ProviderException then the controller catch it and handle the exception.

Which method is better? By the way, this microservice uses Spring framework, not sure if there is a better way to do this in Spring.

spring-boot spring exception design-patterns java
1 Answers

I can propose to declare @ControllerAdvice\@RestControllerAdvice and handle Exception.class in your controller service. When the exception in provider will be thrown, your controller will show pretty response body with your exception.

But, it is always a good practice to handle proper exceptions and not just abstractions.

user_191295320
Related