Nous avons une architecture basée sur des micro-services qui se compose du module principal du serveur d'applications et des modules libs. Dans le serveur d'applications principal, nous acceptons simplement la requête et fournissons une réponse via un objet de requête et de réponse sur les méthodes de l'API REST qui appellent les couches de service disponibles dans le module libs.
public Response restAPI(Request request) {
try {
response.setMessage(service.serviceLayerMethod());
response.setSuccess(true);
} catch (CustomException e) {
response.setMessage(e.getMessage());
response.setSuccess(false);
}
return response
}
Pour propager les messages d'erreur afin qu'ils peuvent être envoyés aux clients en utilisant Response Object (disponible uniquement dans les classes Controller), nous lançons des exceptions personnalisées dans la couche de service, afin que nous puissions envoyer un message d'erreur aux classes Controller. Le problème avec cette approche est que nous lançons une exception dans tous les cas à titre d'exemple, nous lançons une exception même lorsqu'une entrée n'est pas correcte ou lorsque l'utilisateur n'a pas l'autorisation, où nous pouvons simplement renvoyer une réponse à l'utilisateur avec le message d'erreur.
Ma question est la suivante: Est-ce une approche correcte de lancer une exception personnalisée juste pour propager les messages d'erreur de la couche de service au contrôleur? Si NON, comment pouvons-nous propager le message d'erreur vers la couche contrôleur?
Couche service ---
public String serviceLayerMethod(String param) throws AssetException {
try {
if(param==null){
throw new CustomException;
} else{
return param;
}
} catch (CustomException e) {
LOGGER.error(CustomExceptionEnum.PARAMNULL_EXCEPTION.getMessage(),e);
throw new CustomException(CustomExceptionEnum.PARAMNULL_EXCEPTION.getMessage(), e);
}
}
Couche contrôleur ---
parent--
------apps
---server
---Controller Class
------libs
---core
---Service Layer
---Dao Layer
4 Réponses :
Je pense qu'il est logique de consigner l'erreur et d'afficher simplement l'erreur HTTP à l'erreur, par exemple BAD_REQUEST ou INTERNAL_SERVER_ERROR ...
Je ne vois aucun problème à faire cela, mais vous pouvez faire mieux en utilisant Spring pour le faire pour vous sur votre API Rest.
Sur Spring, vous pouvez utiliser @RestControllerAdvice et @ExceptionHandler pour intercepter toute exception et renvoyer un joli message à l'utilisateur. Comme:
@Slf4j
@RestControllerAdvice
public class ErrorHandlerController {
@ExceptionHandler(CustomException.class)
public ResponseEntity<ApiErrorResponse> handleApiException(CustomException ex, Locale locale) {
log.error("Custom error catch with the code {}", ex.getErrorCode(), ex);
ApiErrorResponse error = new ApiErrorResponse(ex, locale);
return new ResponseEntity<>(error, ex.getHttpStatus());
}
}
Ceci est une sujet complexe et subtil - il pourrait bien être basé sur une opinion.
Premièrement, évitez d'utiliser des exceptions pour communiquer la logique de l'application. Votre exemple ne suggère pas que vous faites cela, mais souvent des exceptions personnalisées sont utilisées pour communiquer la logique d'application ou de domaine, et la gestion de cela dans un bloc try / catch est difficile à lire, à tester et à faire évoluer. Par exemple, si un achat échoue parce que le client a dépassé sa limite de crédit (une règle commerciale), j'éviterais d'utiliser une exception personnalisée pour gérer cette instance.
Deuxièmement, essayez d'utiliser les exceptions intégrées, plutôt que de créer les vôtres. Java a plusieurs exceptions intégrées pour la validation des paramètres; vous n'ajoutez aucune valeur en les dupliquant. Créez uniquement des exceptions personnalisées lorsque vous ne trouvez pas d'exception Java intégrée.
Troisièmement, essayez de gérer les exceptions d'application dans la couche contrôleur si vous le pouvez - pousser tout vers le bas dans la couche service rend cette couche plus compliquée et plus difficile à tester.
Enfin, concentrez-vous sur la manière dont vous communiquez vos erreurs à votre client - le modèle courant consiste à utiliser des codes d'erreur HTTP. Finalement, vous pouvez finir par traduire votre exception personnalisée en un code "HTTP: 500", et vous voulez que vos applications clientes puissent raisonner sur ces exceptions de manière cohérente.
Comme Neville l'a souligné; c'est un sujet discutable et rien n'est vraiment bien ou mal ..
Mon opinion est que l'API devrait être indépendante de l'interface utilisateur. Donc, si une exception lève une exception .. il est correct de la renvoyer .. et de laisser le client le gérer ou de décider quoi faire avec cette exception .. Parce que certains clients voudront peut-être montrer un beau message convivial; whlie autre client pourrait vouloir le message réel (par exemple si un autre algorithme appelle cette API).