Salut,
Envoyé par
VS7EVEN
Retourner null je ne suis pas fan (tout comme retourner un objet incorrect) parce que ça veut dire qu'il faut vérifier plus haut la référence.
C'est assez courant pourtant. Et c'est toujours mieux que de renvoyer n'importe quoi. A défaut de soulever une exception, il te faudra retourner quelque chose. Faire un code du genre :
1 2 3 4 5 6 7
| Machin machin = dao.getMachin(id);
if ( machin!=null ) {
//
}
else {
//
} |
n'est pas abérrant et plutôt usuel.
Avec Optional, tu auras plutôt :
1 2
| Optional<Machin> machin = dao.getMachin(id);
machin.ifPresent( ... ); |
ou
1 2 3 4 5 6 7
| Machin machin = dao.getMachin(id);
if ( machin.isPresent() ) {
//
}
else {
//
} |
Envoyé par
VS7EVEN
L'exception me plait bien mais de coup ça peut être vite chiant si elle doit remonter quelques appels de méthodes plus haut, à moins qu'on qu'il y ai un méthode pour éviter ce genre de problèmes.
Bah, ça c'est courant aussi. Et puis l'exception dans un truc du genre :
Machin machin = dao.getMachin(id);
ça permet de distinguer précisemment les cas (pas d'objet avec l'id demandé, pas de table, pas de base ou connexion perdue, etc.).
Si c'est imposer le catch() qui t'ennuie, tu peux utiliser une RuntimeException, mais ça aura le défaut que l'utilisateur du DAO devra être rigoureux et s'intéresser aux exceptions, sinon, elles remonteront tout en haut du thread, et son programme risque de planter salement, au lieu d'avoir une gestion d'erreur au poil, du genre afficher un message quand l'utilisateur demande un objet inexistant, et se reconnecter automatiquement si la connexion est perdue, ou afficher un message d'avertissement (ou d'attente) si la connexion ne peut pas être rétablie, etc.
Envoyé par
VS7EVEN
Mais du coup le pattern DAO ne définit pas spécialement comment gérer ce type de cas ? C'est au développeur à choisir ?
Le pattern, c'est une question d'architecture, pas vraiment de traitement d'erreur. Après, niveau architecture, il y a différentes façosn de résoudre le cas. On peut opter par exemple par une solution par callback :
public void processMachin(String id, Consumer<Machin> ifSucceed)
et
public void processMachin(String id, Consumer<Machin> ifSucceed, BiConsumer<String,Exception> inCaseOfError)
et
public Machin getMachin(String id, Consumer<Machin> ifSucceed, Consumer<String> ifUnknown, BiConsumer<String,Exception> inCaseOfError)
L'appelant choisit d'appeler la méthode qu'il veut, en fournissant les handlers de callback qu'il veut gérer. Et ce n'est pas exclusif à l'implémentation classique pour celui qui veut utiliser l'appel classique avec try/catch et tout.
Partager