Spring Exception Handling. Eccezione personalizzata per stato Http?

-1

Sto solo progettando la gestione delle eccezioni per l'interfaccia REST sul nostro server Spring.

Poiché avremo più controller REST, è necessaria una gestione centrale delle eccezioni. Spring offre la soluzione tramite @ControllerAdvice . Funziona bene, tranne che devo aggiungere una dipendenza alla parte MVC di Spring, che non uso altrove (se qualcuno conosce una soluzione migliore senza questa dipendenza, sarei più che felice).

La mia idea è creare diverse eccezioni come NotFoundException e BadRequestException . Queste eccezioni possono essere utilizzate in un controller di riposo per provocare intenzionalmente una determinata risposta di errore con uno stato Http in base all'eccezione. Inoltre, qualsiasi eccezione non controllata che verrà catturata nel mio gestore di eccezioni @ControllerAdvice , genererà anche un'eccezione di stato http personalizzata.

Mi sembra che in questo modo, posso combinare una gestione centrale delle eccezioni con un codice ben leggibile. Ci sono problemi o pensieri a riguardo?

Esempio di un controller REST

@RestController
@RequestMapping(ExampleRest.EXAMPLE_URI)
public class ExampleRest {

    public static final String EXAMPLE_URI = "/examples";

     @ Autowired
    private ExampleService exampleService;

     @ RequestMapping(value = "/{id}", method = GET)
    public ExampleDto get( @ PathVariable long id) {
        ExampleDto resultingExampleDto = exampleService.findById(id);
        if (resultingExampleDto != null) {
            return resultingExampleDto;
        }
        throw new NotFoundException(); //<- throwing the NotFound (404) exception
    }
}

Gestore errori centrale

@EnableWebMvc
@ControllerAdvice
public class RestResponseEntityExceptionHandler extends ResponseEntityExceptionHandler {

//Exception handling
    @ExceptionHandler(value = {ConstraintViolationException.class})
    protected void handleConstraintViolation(ConstraintViolationException ex, WebRequest request) {
    throw new BadRequestException(ex.getMessage());
    }
//Exception handling
    @ExceptionHandler(value = IllegalArgumentException.class)
    protected void handleIllegalArgument(IllegalArgumentException ex, WebRequest request) {
    throw new BadRequestException(ex.getMessage());
    }

//actual request answer
    @ExceptionHandler(value = BadRequestException.class)
    protected ResponseEntity<Object> returnBadRequest(Exception ex, WebRequest request) {
    return handleExceptionInternal(ex, ex.getMessage(), new HttpHeaders(), HttpStatus.BAD_REQUEST, request);
    }

//actual request answer
    @ExceptionHandler(value = NotFoundException.class)
    protected ResponseEntity<Object> returnNotFound(Exception ex, WebRequest request) {
    return handleExceptionInternal(ex, ex.getMessage(), new HttpHeaders(), HttpStatus.NO_CONTENT, request);
    }

}
    
posta Herr Derb 28.08.2017 - 10:12
fonte

1 risposta

1

In genere eviterei questo approccio. Tendo a pensare che il tipo di un'eccezione dovrebbe fornire informazioni semantiche sulla causa dell'eccezione che dovrebbe di solito essere in termini del tuo dominio problematico . Limitando i tipi di eccezione ai codici di risposta HTTP che verranno generati, si restringono le informazioni fornite dall'eccezione solo alla piccola parte delle informazioni del dominio che ha l'equivalenza diretta alle condizioni di errore HTTP.

Consideriamo, ad esempio, che c'è una differenza tra un ID cliente non trovato e un ID prodotto - potresti voler essere in grado di gestirli diversamente dal lato client e potenzialmente registrarli in modo diverso anche sul lato server. Quindi ha senso avere NoSuchClientException e NoSuchProductException , entrambi i quali produrrebbero una risposta 404 quando gestiti dal framework. Un generico NotFoundException non sarebbe in grado di codificare la differenza tra questi in modo utile.

    
risposta data 28.08.2017 - 11:01
fonte

Leggi altre domande sui tag