I have a little microservice architecture with 3 depending services. Each service represents a seperate Spring Boot project. If an exception occurs on the lowest level of the architecture I would like to throw it through all other services up to the highest/user endpoint service.
Each service API returns a HttpEntity(Response Entity) including a specific object. I found a lot of possible solutions like ResponseEntityExceptionHandlers but all examples shown for a single service architecture without multiple depending services.
Are there any best practices how to throw an Exception through multiple services with Spring Boot?
Assuming that you have three services A (relates directly on B), b (relates directly on C) and C and user calls your service A, but it can be applied to any number of services.
I will briefly describe you the approach
If error occurs in the service C (exception thrown), your code should catch Exception and return a meaningful response. Simplest I can think of would be a #ControllerAdvice
#ControllerAdvice
public class GlobalExceptionHandler {
#ExceptionHandler(YourException.class)
public ResponseEntity<ApiErrorDto> handleYourException(YourException e) {
return ResponseEntity
.status(HttpStatus.BAD_REQUEST) //or any other suitable
.body(new ApiError(e.getMessage());
}
}
ApiError could be just a basic POJO class with a single field holding the message, or any other field meaningful for your exception handling.
Now when your service B receives response it should check whether it is expected status code or an error status code and act accordingly.
Your ApiError class should be shared between all services so that it can be easily serialized/deserialized everywhere. That way once you receive error you can decide what to do next, one of the scenarios could be throwing another exception to be caught by ExceptionHandler in service B.
It's a starter, you can decide whether you want to return a string message in your ApiError, or maybe some kind of a meaningful code etc. Bottom line is that you should include that information in the response of the service where error occurs and interpret that information in the calling service.
Related
I have been trying to implement hystrix fallback to only throw Exception rather than raking a response.
I have been searching up and down for ways to have the fallback method to only throw Exceptions. The whole point of implementing Hystrix here is main to preserve resources and close unnecessary call to another MS that is already down and I need to standardize the response (throw Exception) regardless of what is the originally intended response.
Here is the rough implementation that i'm trying
#HystrixCommand(fallBackMethod="fallback")
public String actualMethod(String input){
code to call another MS
}
private String fallback(String input){
throw RuntimeException("Some specific error message");
}
However, i kept getting fallback failed.
A pointer somewhere would be great. Thanks people
There is a typo in your code #HystrixCommand(fallBackMethod="fallback") should be #HystrixCommand(fallbackMethod="fallback")
Code convention says no logic in the controllers. All should be handled in the service layer. My question is especially about returning ResponseEntity.
Should it be handled in RestController or in Service layer?
I tried both ways. I think RestController is the suitable place to return ResponseEntity. Because we are using mappings in the RestController.
On the other hand, we know the controllers should not include any logic.
#GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(#PathVariable Long id) {
return ResponseEntity.ok(employeeService.findEmployeeById(id);
}
or
#GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(#PathVariable Long id) {
return employeeService.findEmployeeById(id);
}
ControllerAdvice for exception handling is my another concern. Which way is the best to use?
Thanks for your advance.
Code convention says no logic in the controllers.
Not really. Code convention says each layer has to perform itself logic which it is responsible of.
Computing the result, retrieving data requested/needed by the request is clearly not the rest controller job but sending an http response, what returning ResponseEntity does is its job. So this looks the correct way :
#GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(#PathVariable Long id) {
return ResponseEntity.ok(employeeService.findEmployeeById(id);
}
If the ResponseEntity was produced by your service, your service would be coupled with the Http layer. Not desirable and make it less reusable as a service.
Status Code, Response Body, Headers are one of the core parts for REST
The controller should be concerned with accepting the request, asking the correct domain service to process the request, and handing off the response to the correct place.
It's right that controllers should not perform all business logic here but sending the HTTP response should be done in Controller instead of service.
Although Status code can be sent using #ResponseStatus(HttpStatus.XXX) which might not be helpful for in scenarios where we have to send Status Code according to the conditions. You can create custom ResponseDTO which generally have body, message and status code.
public ResponseEntity<ResponseDTO> method() {
return new ResponseEntity<ResponseDTO>(response,response.getStatus());
}
First. The business logic should be handled in the service layer where you are able to abstract the data access with repository. This aides modular programming, reusable pieces of codes decoupled from each other. This is the idea behind Model, View, Controller(MVC), the underlying design. In terms of testing, it will be easier to have these parts of the application do their part of the job and testing independent of one another. Abstracting your logic in the service method also helps when we are dealing with security access to specific methods not URL which the controller gives us the ability. Therefore, your RestController should call your service layer and return appropriate response.
Second. For your (Rest) ControllerAdvice, having your exception handler aids in returning custom errors. Here is an example below inside the exception handler class.
#ExceptionHandler(CustomerExistException.class)
public final ResponseEntity<ApiErrorResponse> handleCustomerExistException(
CustomerExistException ex) {
ApiErrorResponse errorResponse = new ApiErrorResponse("USR_04", "The email already exists."
+ "Email", String.valueOf(HttpStatus.BAD_REQUEST));
return new ResponseEntity<ApiErrorResponse>(errorResponse, HttpStatus.BAD_REQUEST);
}`
I have a SpringBoot based REST Api structured as follows :
Rest Controller -> Service -> Repository
and I'm wondering how exactly to handle exceptions "properly".
For instance, let's say someone calls a /myresources/{id} endpoint with a non-existant {id}. The call gets delegated to the service which in turns tries to get the MyResource from the Repository. It fails and returns null. The Service then throws a MyResourceNotFoundException.
Now I want a specific format for my REST errors so I have a #ControllerAdvice ResponseEntityExceptionHandler which handles the custom serialization of these exceptions (#ExceptionHandler(MyResourceNotFoundException.class)).
Fine.
But this is going to result in a lot of handling/translation for each different custom exception. So I thought I could generify this by adding HttpStatus codes and messages to a base abstract exception class which MyResourceNotFound and others would extend and override. Thus the ResponseEntityExceptionHandler would simply handle building my custom error DTO in a standard way.
But then I realised that I'm adding REST concepts to an exception thrown at the service level. These shouldn't be aware of such notions...
Maybe I should catch the MyResourceNotFoundException in the Controller and throw another layer-specific exception which contains the appropriate messages and HttpStatus etc. in order to handle this generically in the ResponseEntityExceptionHandler...
What are your thoughts on this ?
You can generalize the exception as XYZMicroserviceException.
class XYZGenericException extends Exception{
String message;
custom error details....
XYZgenericException(errorMessage, custom error Details..){
this.message=errorMessage;
.......
}
}
and you can surround the suspected call which would lead to exception with try block and raise the generic exception in catch block that can be handled in global exception handler.
try{
xyz.abcMethod() // may give some exception
}
catch(Exception e){
throw new XYZGenericException(.........)
}
In the exception handler class with #restcontrolleradvice you can annotate the methods with the type of specific exception class to be handled.
I am developing web application with spring + hibernate. As per my knowledge, it is best practice to put #transactional in service layer. Spring throws DataAccessException in case of any exception while updating data into database.
Below is my high level class structure.
#Transactional
class OrderService {
public void createOrder() {
try {
orderDAO.createOrder();
} catch (DataAccessException e) {
// convert into business exception and sends back to presentation logic.
}
}
}
What happens here is data access exception is thrown only after completion of method. so if any exception occurs, I am not able to convert it into business exception in catch block.
Work around is to flush the hibernate session in dao method but I do not like this approach. Is there any better approach to this?
I presume you are using Spring MVC, although you do not specify. If you are using Spring MVC, then there are a few different options.
You can create a Filter that looks for the DAE exception and recodes it to be a different status or exception that your front end would better understand. You can look at Spring Security's ExceptionTranslationFilter as an example of how this is already done for different exceptions
You can use a SimpleMappingExceptionResolver to map a specific exception to a particular view. This would allow your presentation layer to be agnostic and not need to know anything about the exception thrown.
You can use an #ExceptionHandler within a specific controller to handle the DAE exception in a general manner and appropriately prepare something for the presentation layer.
As an extension to #3, you can use a #ControllerAdvice to manage all DAE exceptions for any controllers in the webapp.
You can read about Exception Handling in Spring MVC for more details as well.
Generally speaking, I find that the best solution is to catch transaction exceptions at a much higher level and manipulate the information to present it to the front end in a way that is back-end agnostic. This allows you to set up your own error codes/etc. The only time I try/catch exceptions in my service itself is if I actually want to attempt a retry or modify the logic flow based on some specific exception and don't want the front end to know about it.
I'm using Google's Preconditions class to validate user's input data.
But I'm worried about where is the best point of checking user's input data using Preconditions class.
First, I wrote validation check code in Controller like below:
#Controller
...
public void register(ProductInfo data) {
Preconditions.checkArgument(StringUtils.hasText(data.getName()),
"Empty name parameter.");
productService.register(data);
}
#Service
...
public void register(ProductInfo data) {
productDao.register(data);
}
But I thought that register method in Service layer would be using another Controller method like below:
#Controller
...
public void register(ProductInfo data) {
productService.register(data);
}
public void anotherRegister(ProductInfo data) {
productService.register(data);
}
#Service
...
public void register(ProductInfo data) {
Preconditions.checkArgument(StringUtils.hasText(data.getName()),
"Empty name parameter.");
productDao.register(data);
}
On the other hand, the method of service layer would be used in just one controller.
I was confused. Which is the better way of checking preconditions in controller or service?
Thanks in advance.
Ideally you would do it in both places. But you are confusing two different things:
Validation (with error handling)
Defensivie Programming (aka assertions, aka design by contract).
You absolutely should do validation in the controller and defensive programming in your service. And here is why.
You need to validate for forms and REST requests so that you can send a sensible error back to the client. This includes what fields are bad and then doing localization of the error messages, etc... (your current example would send me a horrible 500 error message with a stack trace if ProductInfo.name property was null).
Spring has a solution for validating objects in the controller.
Defensive programming is done in the service layer BUT NOT validation because you don't have access to locale to generate proper error messages. Some people do but Spring doesn't really help you there.
The other reason why validation is not done in the service layer is that the ORM already typically does this through the JSR Bean Validation spec (hibernate) but it doesn't generate sensible error messages.
One strategy people do is to create their own preconditions utils library that throws custom derived RuntimeExceptions instead of guava's (and commons lang) IllegalArgumentException and IllegalStateException and then try...catch the exceptions in the controller converting them to validation error messages.
There is no "better" way. If you think that the service is going to be used by multiple controllers (or other pieces of code), then it may well make sense to do the checks there. If it's important to your application to check invalid requests while they're still in the controller, it may well make sense to do the checks there. These two, as you have noticed, are not mutually exclusive. You might have to check twice to cover both scenarios.
Another possible solution: use Bean Validation (JSR-303) to put the checks (preconditions) onto the ProductInfo bean itself. That way you only specify the checks once, and anything that needs to can quickly validate the bean.
Preconditions, validations, whether simple or business should be handled at the filter layer or by interceptors, even before reaching the controller or service layer.
The danger if you check it in your controller layer, you are violating the single responsibility principle of a controller, whose sole purpose is to delegate request and response.
Putting preconditions in service layer is introducing cross cutting concerns to the core business.
Filter or inceptor is built for this purpose. Putting preconditions at the filter layer or in interceptors also allow you to “pick and match” rules you can place in the stack for each servlet request, thus not confining a particular rule to only one servlet request or introduce duplication.
I think in your special case you need to to check it on Service layer and return exception to Controller in case of data integrity error.
#controller
public class MyController{
#ExceptionHandler(MyDataIntegrityExcpetion.class)
public String handleException(MyDataIntegrityExcpetion ex, HttpServletRequest request) {
//do someting on exception or return some view.
}
}
It also depend on what you are doing in controller. whether you return View or just using #ResponseBody Annotation. Spring MVC has nice "out of the box" solution for input/dat validation I recommend you to check this libraries out.
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/validation.html