Controles des paramètres d'entrée
Résolu/Fermé
polak1982
Messages postés
11
Date d'inscription
dimanche 24 novembre 2013
Statut
Membre
Dernière intervention
6 septembre 2021
-
20 juin 2015 à 17:29
polak1982 Messages postés 11 Date d'inscription dimanche 24 novembre 2013 Statut Membre Dernière intervention 6 septembre 2021 - 20 juin 2015 à 21:23
polak1982 Messages postés 11 Date d'inscription dimanche 24 novembre 2013 Statut Membre Dernière intervention 6 septembre 2021 - 20 juin 2015 à 21:23
A voir également:
- Controles des paramètres d'entrée
- Paramètres windows - Guide
- Paramètres de confidentialité - Guide
- Paramètres dns - Guide
- Paramètres iphone - Guide
- Le bon coin mon compte parametres - Guide
1 réponse
KX
Messages postés
16755
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
12 février 2025
3 020
20 juin 2015 à 18:13
20 juin 2015 à 18:13
Bonjour,
Je trouve la conception de tes deux classes un peu bizarre...
Je reprends pas à pas :
1)
Pourquoi est-ce que tu renverrais des WsBusinessErrorMsg ou WsSystemErrorMsg ici, ça n'a pas de sens, tu fais juste des getter et setter sur des beans, je ne vois pas où tu vas trouver des erreurs !
De plus grosses infractions aux conventions de nommage, que ce soit le type de données ryType, le paramètre beneficiaryREQUEST, ou pire, tes deux Throwable dont on ne sait même pas si ce sont des Exception ou des Error...
2)
Ici, tu fais des "calculs" complètement faux, d'une part tu ne vérifies pas que getNni peut valoir null, ensuite tu vérifies que le substring est différent de null (ce qui est impossible, cette méthode ne renvoie jamais null) mais tu ne vérifies pas avant de faire le substring que effectivement la taille de ce String est autorisée... Bref ça va planter facilement !
De plus l'utilisation du Logger est critiquable, le but de ta méthode est de te renvoyer un bean bien formé, or tu ne settes pas tous les champs, et si le champ est absent tu mets juste un avertissement au fin fond d'un fichier de log que personne ne lis jamais... Il faut être plus violent et envoyer une exception si le bean d'entrée est mal formé.
3)
Pareil, d'une part il n'y a pas de raison d'avoir eu des erreurs techniques au préalable sur de la manipulation de bean, et même si tu en avais eu pourquoi ne pas utiliser ton Logger plutôt que de faire un printStackTrace ?
Quant à ta question, les deux conditions sont incompatibles
1 - La donnée nir doit être renseignée
2 - Si nir absent, les données nom et prenom doient être renseignées.
Il n'y a pas de raison de traiter le cas où nir est absent alors qu'il doit être renseigné... il faut faire un choix c'est l'un ou l'autre, ou alors il faut préciser le mode que tu souhaites avec un booléen en paramètre.
Exemple :
Je trouve la conception de tes deux classes un peu bizarre...
Je reprends pas à pas :
1)
public IdentificationRequestBean formatEntret( ryType beneficiaryREQUEST) throws WsBusinessErrorMsg, WsSystemErrorMsg {
Pourquoi est-ce que tu renverrais des WsBusinessErrorMsg ou WsSystemErrorMsg ici, ça n'a pas de sens, tu fais juste des getter et setter sur des beans, je ne vois pas où tu vas trouver des erreurs !
De plus grosses infractions aux conventions de nommage, que ce soit le type de données ryType, le paramètre beneficiaryREQUEST, ou pire, tes deux Throwable dont on ne sait même pas si ce sont des Exception ou des Error...
2)
/* Récupération du champ NIR */ if (beneficiaryREQUEST.getNni().substring(0, 13) != null || beneficiaryREQUEST.getNni().length() < 13) { idReq.setNni(beneficiaryREQUEST.getNni()); } else LogHelper.info(getClass(), meth, "Le nir est absent/ou incomplet");
Ici, tu fais des "calculs" complètement faux, d'une part tu ne vérifies pas que getNni peut valoir null, ensuite tu vérifies que le substring est différent de null (ce qui est impossible, cette méthode ne renvoie jamais null) mais tu ne vérifies pas avant de faire le substring que effectivement la taille de ce String est autorisée... Bref ça va planter facilement !
De plus l'utilisation du Logger est critiquable, le but de ta méthode est de te renvoyer un bean bien formé, or tu ne settes pas tous les champs, et si le champ est absent tu mets juste un avertissement au fin fond d'un fichier de log que personne ne lis jamais... Il faut être plus violent et envoyer une exception si le bean d'entrée est mal formé.
3)
} catch (Exception ex) { //Gestion des erreurs techniques ex.printStacktrace(); }
Pareil, d'une part il n'y a pas de raison d'avoir eu des erreurs techniques au préalable sur de la manipulation de bean, et même si tu en avais eu pourquoi ne pas utiliser ton Logger plutôt que de faire un printStackTrace ?
Quant à ta question, les deux conditions sont incompatibles
1 - La donnée nir doit être renseignée
2 - Si nir absent, les données nom et prenom doient être renseignées.
Il n'y a pas de raison de traiter le cas où nir est absent alors qu'il doit être renseigné... il faut faire un choix c'est l'un ou l'autre, ou alors il faut préciser le mode que tu souhaites avec un booléen en paramètre.
Exemple :
public IdentificationRequestBean format(RyType beneficiaryRequest, boolean nniRequired) { if (beneficiaryRequest == null) throw new IllegalArgumentException("beneficiaryRequest should not be null"); String nni = beneficiaryRequest.getNni(); String name = beneficiaryRequest.getName(); String firstname = beneficiaryRequest.getFirstname(); if (nni == null) { if (nniRequired) throw new IllegalStateException("nni is required but is null"); if (name == null) throw new IllegalStateException("nni is null so name is required but is null"); if (firstname == null) throw new IllegalStateException("nni is null so firstname is required but is null"); } else { if (nni.length() >= 13) nni = nni.substring(0, 13); } return new IdentificationRequestBean(nni, name, firstname); }
20 juin 2015 à 21:23
Ne t'en fait pas pour les exceptions, ce qui m'importait c'était juste l'algorithme en tout cas grand merci.
Mon application permet de retrouver un client par sont nir (C'est le premier critère de recherche)
On doit aussi retrouver la personne avec son nom et prénom.
Merci