Si ça marche pour toi, tant mieux, mais je doute que ça soit le cas pour beaucoup d’applis.
Sur les erreurs dures, que tu ne peux pas corriger, t’as probablement envie de mapper les erreurs en fonction du contexte. Y’a une différence entre « tu m’as passer un uuid quand je m’attend à un int », auquel cas tu veux retourne un 400 bad request, et un « je me suis pété une NPE, et je veux retourner un 500 », avec tout un spectre entre les deux (404 not found, 503, 406, 429, que sais je encore), et tu peux vouloir remonter un code d’erreur applicatif a ton client aussi.
Et en fonction du besoin, certaine partie du traitement peuvent être optionnelles, et la requête peut être complétée sans forcément tout faire. Typiquement, sur un read only qui agrège des données de multiples sources, ce qui est somme toute très courant dans un monde soa. Et la croit moi, tu veux les catcher ces exceptions la.
[^] # Re: Kamoulox !
Posté par groumly . En réponse au journal Golang, oops you did it again. Évalué à 4.
Si ça marche pour toi, tant mieux, mais je doute que ça soit le cas pour beaucoup d’applis.
Sur les erreurs dures, que tu ne peux pas corriger, t’as probablement envie de mapper les erreurs en fonction du contexte. Y’a une différence entre « tu m’as passer un uuid quand je m’attend à un int », auquel cas tu veux retourne un 400 bad request, et un « je me suis pété une NPE, et je veux retourner un 500 », avec tout un spectre entre les deux (404 not found, 503, 406, 429, que sais je encore), et tu peux vouloir remonter un code d’erreur applicatif a ton client aussi.
Et en fonction du besoin, certaine partie du traitement peuvent être optionnelles, et la requête peut être complétée sans forcément tout faire. Typiquement, sur un read only qui agrège des données de multiples sources, ce qui est somme toute très courant dans un monde soa. Et la croit moi, tu veux les catcher ces exceptions la.