Problema Spring Web é um conjunto de bibliotecas que facilita a produção de application/problem+json de um aplicativo de primavera. Ele preenche um nicho, na medida em que conecta a biblioteca de problemas e o manuseio de exceções da Spring Web MVC ou o manuseio de exceções do Spring Webflux, para que eles trabalhem perfeitamente juntos, exigindo um esforço mínimo de desenvolvedor adicional. Ao fazer isso, ele pretende executar uma tarefa pequena, mas repetitiva - de uma vez por todas.
A maneira como essa biblioteca funciona é baseada no que chamamos de traços de conselhos . Um traço de conselho é um pequeno e reutilizável @ExceptionHandler implementado como um método padrão colocado em uma única interface de método. Esses traços de conselho podem ser combinados livremente e não precisam usar uma classe base comum para o seu @ControllerAdvice .
? Por favor, confira Baeldung: um guia para o problema Spring Web Library para uma introdução detalhada!
O processo de manuseio de problemas fornecido pelo AdviceTrait é construído de uma maneira que permita a personalização sempre que surgir necessidade. Todos os seguintes aspectos (e mais) podem ser personalizados implementando a interface de característica de aconselhamento apropriada:
| Aspecto | Métodos (s) | Padrão |
|---|---|---|
| Criação | AdviceTrait.create(..) | |
| Log | AdviceTrait.log(..) | 4xx como WARN , 5xx como ERROR incluindo rastreamento de pilha |
| Negociação de conteúdo | AdviceTrait.negotiate(..) | application/json , application/*+json , application/problem+json E application/x.problem+json |
| Cair pra trás | AdviceTrait.fallback(..) | application/problem+json |
| Pós-processamento | AdviceTrait.process(..) | n / D |
O exemplo a seguir personaliza o MissingServletRequestParameterAdviceTrait , adicionando um campo de extensão de parameter ao Problem :
@ ControllerAdvice
public class MissingRequestParameterExceptionHandler implements MissingServletRequestParameterAdviceTrait {
@ Override
public ProblemBuilder prepare ( Throwable throwable , StatusType status , URI type ) {
var exception = ( MissingServletRequestParameterException ) throwable ;
return Problem . builder ()
. withTitle ( status . getReasonPhrase ())
. withStatus ( status )
. withDetail ( exception . getMessage ())
. with ( "parameter" , exception . getParameterName ());
}
}Supondo que exista um controlador como este:
@ RestController
@ RequestMapping ( "/products" )
class ProductsResource {
@ RequestMapping ( method = GET , value = "/{productId}" , produces = APPLICATION_JSON_VALUE )
public Product getProduct ( String productId ) {
// TODO implement
return null ;
}
@ RequestMapping ( method = PUT , value = "/{productId}" , consumes = APPLICATION_JSON_VALUE )
public Product updateProduct ( String productId , Product product ) {
// TODO implement
throw new UnsupportedOperationException ();
}
}As seguintes solicitações HTTP produzirão a resposta correspondente, respectivamente:
GET /products/123 HTTP/1.1
Accept: application/xml HTTP/1.1 406 Not Acceptable
Content-Type: application/problem+json
{
"title" : " Not Acceptable " ,
"status" : 406 ,
"detail" : " Could not find acceptable representation "
} POST /products/123 HTTP/1.1
Content-Type: application/json
{} HTTP/1.1 405 Method Not Allowed
Allow: GET
Content-Type: application/problem+json
{
"title" : " Method Not Allowed " ,
"status" : 405 ,
"detail" : " POST not supported "
}Antes de continuar , leia a seção sobre traços de pilha e cadeias causais em Zalando/Problem.
Caso você queira ativar traços de pilha, configure o seu ProblemModule da seguinte forma:
ObjectMapper mapper = new ObjectMapper ()
. registerModule ( new ProblemModule (). withStackTraces ());As cadeias causais de problemas são desativadas por padrão , mas podem ser substituídas, se desejar:
@ ControllerAdvice
class ExceptionHandling implements ProblemHandling {
@ Override
public boolean isCausalChainsEnabled () {
return true ;
}
} Nota Como você tem acesso total ao contexto do aplicativo nesse ponto, você pode externalizar a configuração para o seu application.yml e até decidir reutilizar a propriedade server.error.include-stacktrace .
Habilitar ambos os recursos, correntes causais e Stacktraces, produzirá:
{
" title " : " Internal Server Error " ,
" status " : 500,
" detail " : " Illegal State " ,
" stacktrace " : [
" org.example.ExampleRestController.newIllegalState(ExampleRestController.java:96) " ,
" org.example.ExampleRestController.nestedThrowable(ExampleRestController.java:91) "
],
" cause " : {
" title " : " Internal Server Error " ,
" status " : 500,
" detail " : " Illegal Argument " ,
" stacktrace " : [
" org.example.ExampleRestController.newIllegalArgument(ExampleRestController.java:100) " ,
" org.example.ExampleRestController.nestedThrowable(ExampleRestController.java:88) "
],
" cause " : {
" title " : " Internal Server Error " ,
" status " : 500,
" detail " : " Null Pointer " ,
" stacktrace " : [
" org.example.ExampleRestController.newNullPointer(ExampleRestController.java:104) " ,
" org.example.ExampleRestController.nestedThrowable(ExampleRestController.java:86) " ,
" sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) " ,
" sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) " ,
" sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) " ,
" java.lang.reflect.Method.invoke(Method.java:483) " ,
" org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) " ,
" org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) " ,
" org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) " ,
" org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) " ,
" org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) " ,
" org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) " ,
" org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) " ,
" org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) " ,
" org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) " ,
" org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) " ,
" org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) " ,
" org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) " ,
" org.junit.runners.ParentRunner.run(ParentRunner.java:363) " ,
" org.junit.runner.JUnitCore.run(JUnitCore.java:137) " ,
" com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117) " ,
" com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234) " ,
" com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74) "
]
}
}
} A primavera permite restringir o escopo de um @ControllerAdvice a um determinado subconjunto de controladores:
@ ControllerAdvice ( assignableTypes = ExampleController . class )
public final class ExceptionHandling implements ProblemHandlingAo fazer isso, você perderá a capacidade de lidar com certos tipos de exceções, a saber:
HttpRequestMethodNotSupportedExceptionHttpMediaTypeNotAcceptableExceptionHttpMediaTypeNotSupportedExceptionNoHandlerFoundException Herdamos essa restrição da primavera e, portanto, recomendamos usar um @ControllerAdvice irrestrito.
Se você tiver dúvidas, preocupações, relatórios de bugs etc., registre um problema no rastreador de problemas deste repositório.
Para contribuir, basta fazer uma solicitação de tração e adicionar uma breve descrição (1-2 frases) da sua adição ou alteração. Para mais detalhes, verifique as diretrizes de contribuição.