Aspect selon valeur retourn�e

Bonjour.

J'ai une application qui fait appel � une API externe PersonAPI de cette fa�on :

Code java :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
public void modifierPersonne() {
    //Traider input
    PersonDto output = personApi.modify(input);
    //Traiter output
}
public void creerPersonne() {
    //Traider input
    PersonDto output = personApi.create(input);
    //Traiter output
}

L'API retourne ce genre de JSON :

Code JSON :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
{
    code: 200,
    messages: [],
    data: {
        person: {name: "name", age: 100, ...}
    }
}

Probl�me, la gestion des erreurs est mal con�ue et l'API peut retourner un code HTTP 200 avec des donn�es tel que :

Code JSON :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
{
    code: 400,
    messages: [
        severity: "ERROR",
        content: "Invalid character in 'name'"
    ],
    data: {
        person: {name: "א", age: 100, ...}
    }
}

Ce comportement ne pouvant pas changer, je souhaite m'adapter, mais si possible sans toucher au code existant (base de code assez grande).
Les Aspects semblent �tre une bonne solution, j'en utilise d�j� pour log des appels de fonctions tr�s pr�cises.
Je pense intercepter les donn�es de retour et envoyer une exception si le champ severity est "ERROR".

Je voudrais savoir si il est possible d'intercepter le processus juste apr�s que la fonction ait retourn� le JSON (retour de personApi.create()) mais avant que la valeur soit assign�e � p output ?
Sinon si il y existe une option plus pertinente ?

L'API est est une API REST qui tourne sur un serveur, qui se mat�rialise dans le code par le service personApi.

J'aimerais modifier mon programme, mais si possible sans toucher au code que j'ai pr�sent�.

p est un mauvais-copier-coller, c'est output.

Le probl�me, c'est qu'il y a deux �coles sur les exceptions, celle de Java de base, qui est la mienne, et d�crite dans "Effective Java" (https://www.amazon.fr/Effective-Java.../dp/0134685997 ), et celle de Spring.

Je pense que la vision Spring n'est pas bonne, mais c'est un avis perso.
Effectivement, �a peut toujours mal se passer, soit parce que l'utilisateur envoie des donn�es incompl�tes, soit parce que la BDD tombe en panne ou que sais-je!

Si on prend Spring, il n'y a pas d'exception dans la signature des m�thodes (exemple ici: https://docs.spring.io/spring-data/c...epository.html ).

Or, ce n'est pas vrai. En r�alit�, si la BDD crash, alors Spring va renvoyer une RuntimeException ( https://docs.oracle.com/javase/8/doc...Exception.html ).

Dans "Effective Java", au contraire (et dans le Java de base), on diff�rentie les exceptions.
Il y a l'exception de base et la Runtime (celle envoy� par Spring) qui peut toujours �tre envoy�, n'importe quand.

Il est conseill� de mettre dans la signature des m�thodes les exceptions qui peuvent �tre envoy� suite � une erreur "pr�visible" (Erreur de l'utilisateur, plantage de la BDD ...) et laisser la Runtime pour les erreurs du d�veloppeur (NullPointerException �tant la plus connue).

Dans ton cas, je crains que l'on ai pas mis en avant l'exception dans la signature de la m�thode.
Dans ce cas, on peut faire de la fa�on suivante:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public void modifierPersonne() throws ServiceException{
    try{  
      //Traider input
      PersonDto output = personApi.modify(input);
      //Traiter output
    }catch(Exception e){
        throw new MyException(e);
    }
}
public void creerPersonne() throws ServiceException{
    try{
      //Traider input
      PersonDto output = personApi.create(input);
     //Traiter output
    }catch(Exception e){
       throw new MyException(e);
    }
}

Ainsi, tu te laisse le soin d'avoir une gestion centralis�e des exceptions (g�n�ralement dans la couche controller).

Tu peux aussi traiter l'�ventuelle exception dirrectement (en logant ...).

A noter que l'"Exception" est vague. Dans la r�alit�; le personApi jette une RuntimeException. Elle est dans une logique Spring.

Envoy� par thelvin

Bah. Peut-�tre et peut-�tre pas. Si tu as d�j� utilis� des aspects tu dois avoir une id�e de comment �a marche n'est-ce pas ?

Alors comment diable quelqu'un qui n'est pas toi, pourrait-il avoir la moindre id�e de si c'est possible, avec ce que tu nous montres ? Je trouve �trange qu'il y ait besoin de te dire �a, sans que �a te paraisse �vident d�s le d�part.

�videmment, mais le seul usage des aspects que j'ai eu jusqu'� pr�sent �tait pour faire des logs d'appels de certaine fonctions pr�cises (avec @Before). L� je me doute que c'est possible avec des aspects, mais �a m'a l'air d'�tre un cas d'usage beaucoup plus sophistiqu�, puisqu'il faut que j'intercepte un appel. Et c'est �a que je ne savais pas faire lorsque j'ai �crit le post.

Envoy� par thelvin

On rappellera qu'avec le code montr�, personApi.create() ne renvoie absolument pas du JSON, mais un objet PersonDto. Objet qui donc, vraisemblablement, ne contient pas les champs code ni message, ni d'ailleurs le status HTTP qui avait r�ellement �t� r�pondu.

Le champ code correspond au code HTTP, qui est donc dupliqu� dans le JSON. Sinon oui on est d'accord, le JSON est automatiquement converti en DTO, c'�tait peut-�tre un abus de langage de ma part.

Cela dit, j'ai pu avancer dans l'intervalle de temps, j'ai trouv� @Around et ProceedingJoinPoint pjp; pjp.proceed() qui ont l'air de r�pondre � mon besoin.

Code java :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
  @Around("appelApi()")
  public Object detecterErreurApi(ProceedingJoinPoint pjp) throws Throwable {
    Object reponseAPi = pjp.proceed();
    /**throw possible**/
    throw new ErreurApiException();
  }

Mais �a me pose un nouveau souci. Si mon aspect lance une exception personnalis�e (ErreurApiException). �a provoque une erreur de compilation de type UndeclaredThrowableException car modifierPersonne n'a pas throws ErreurApiException d�clar�.
Je pourrais lancer une exception standard, mais si possible j'aimerais garder mon exception.

Malheureusement, si

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

ErreurApiException

n'est pas une runtime et n'est pas dans la signature de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

modifierPersonne

�a na fonctionnera pas. Il faudrait transfomer l'exception en runtime pour que �a fonctionne (comme le sugg�re Thelvin).

Si pas, vous laissez tomber l'aspect et faites un wrapper autour de cette API externe...

Pour ce qui est de lever une exception sans avoir � la d�clarer :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public final class ExceptionThrower{
    private ExceptionThrower(){}
 
    /**
     * 
     * @param ex
     */
    public static void throwException(final Throwable ex){
        ExceptionThrower.<RuntimeException>throwsUnchecked(ex);
    }
 
    /**
     * 
     * @param toThrow
     * @throws T
     */
@SuppressWarnings("unchecked")
    private static <T extends Throwable> void throwsUnchecked(final Throwable toThrow) throws T {
        throw (T) toThrow;
    }
}

et donc au lieu de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

throw new ErreurApiException();

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

ExceptionThrower.throwException(new ErreurApiException());

� vos risques et p�rils, cela va sans dire.

Quant � l'id�e que "la gestion des erreurs est mal con�ue et l'API peut retourner un code HTTP 200 avec des donn�es tel que ..." c'est votre fa�on de voir�
d'autres pourraient consid�rer que les erreurs business sont une r�ponse valide comme une autre et doivent �tre interpr�t�es par le client
et que seules les erreurs de fonctionnement de /communication avec doivent �tre retourn�es avec un code HTTP d'erreur.