Je ne peux pas comprendre comment gérer plus d'un type d'exception avec @ExceptionHandler.
Je dois traiter ces exceptions par programme, pour cela il me faudrait une référence partagée. Cela se fait-il via cette référence "Exception ex"? Je ne pense pas, car l'exception n'est pas interceptée comme ceci, comment pourrais-je le faire alors?
Je ne peux pas mettre toutes les références à l'exception comme arguments de la méthode de gestion, cela n'a aucun sens, cela ne peut pas être traité par programme. J'ai besoin d'une référence partagée pour pouvoir utiliser "instanceof" ou simplement l'envoyer ailleurs comme "exception" générale
@ExceptionHandler({DescriptionCstOrderException.class, SpecializationCstOrderException.class, NoUploadFileException.class,
DeadLineCstOrderException.class, DocumentCstOrderException.class, CommentCstOrderException.class})
public String handleFormException(Exception ex, ActionRequest actionRequest) {
logger.error(ex.getMessage());
SessionErrors.add(actionRequest, ex.getClass().getName());
return "mainOrderForm";
}
Question supplémentaire: que se passe-t-il si je veux gérer une exception org.springframework.web.multipart.MaxUploadSizeExceededException, qui ne soit levée par aucune méthode du gestionnaire? Parce que @ExceptionHandler n'attrape que les exceptions émises par l'une des méthodes de gestionnaire.
La méthode exceptionHandler pourrait être placée dans un contrôleur parent étendu, mais si on utilise uniquement defaultAnnotationHandlerMapping ...?
J'apprécie toute aide, je deviens fou, c'est très frustrant ....
La valeur @ExceptionHandler peut être définie sur un tableau de types d'exception. Si une exception est renvoyée et correspond à l'un des types de la liste, la méthode annotée avec le @ExceptionHandler correspondant sera appelée. Si la valeur d'annotation n'est pas définie, les types d'exception répertoriés en tant qu'arguments de méthode sont utilisés. Voir le documentation pour plus de détails.
La valeur @ExceptionHandler
peut être définie sur un tableau de types d'exception.
L'implémentation de l'utilisation du tableau d'exceptions mentionné dans Spring documentation ressemblera à
@ExceptionHandler({
NotFoundException.class,
MissingServletRequestParameterException.class
})
Votre question est plutôt déroutante, mais votre méthode de gestion des exceptions ne gérera qu'une exception à la fois. Il ne capturera pas plusieurs exceptions, puis les passera dans votre méthode handleFormException (). Si vous devez gérer ces types d'exceptions différemment, vous devez créer une méthode de gestionnaire d'exceptions pour chacun d'entre eux, spécifier un argument de ce type d'exception spécifique pour votre méthode, puis procéder au traitement approprié. Par exemple:
@ExceptionHandler(DescriptionCstOrderException.class)
public String handleDescriptionCstOrderException(DescriptionCstOrderException exception, ActionRequest actionRequest) {...}
@ExceptionHandler(SpecializationCstOrderException.class)
public String handleSpecializationCstOrderException(SpecializationCstOrderException exception, ActionRequest actionRequest) {...}
// and so on...
Veuillez vous reporter à la documentation de Spring pour plus d'informations:
Je suis tombé sur ce problème moi-même. Le problème est apparu lorsque j'ai essayé d'intégrer les méthodes de Bugsnag. Bugsnag attache son thread au Thread.UncaughtExceptionHandler et si le Thread.UncaughtExceptionHandler est déjà géré par un autre mécanisme (dans mon cas: AopUtils avec InvocationTargetException), Bugsnag ne pourra pas le pousser dans son tableau de bord. Bugsnag était supposé fonctionner sans problème avec le traitement des exceptions non gérées, s’il avait été simplement simple et n’avait pas été traité ailleurs au printemps.
Maintenant, je voulais écrire un uniforme ExceptionHandler et je suis tombé sur le @ControllerAdvice du Spring. Pour un scénario, je sais que NullPointerException de n'importe quelle partie de l'application appelle l'invocationTargetException de AopUtil. J'ai donc écrit un @ExceptionHandler traitant InvocationTargetException, mais qu'en est-il de tout autre type d'exception RunTime. Cela peut s'avérer être le cauchemar de la production.
Je veux simplement un mécanisme général qui gèrerait n'importe quel type d'exception, levé de n'importe quelle partie de l'application, pour simplement converger vers cette méthode. Et je crois que c’est exactement ce que @lisak a demandé. Des pensées, quelqu'un?