Il n'y a absolument aucune raison de revenir true
sur le succès si vous ne revenez pas false
sur l'échec. À quoi devrait ressembler le code client?
if (result = tryMyAPICall()) {
// business logic
}
else {
// this will *never* happen anyways
}
Dans ce cas, l' appelant a quand même besoin d'un bloc try-catch, mais il peut alors mieux écrire:
try {
result = tryMyAPICall();
// business logic
// will only reach this line when no exception
// no reason to use an if-condition
} catch (SomeException se) { }
La true
valeur de retour est donc complètement hors de propos pour l'appelant. Il suffit donc de garder la méthode void
.
En général, il existe trois façons de concevoir des modes de défaillance.
- Retour vrai / faux
- Utiliser
void
, lever (vérifié) l'exception
- renvoie un objet de résultat intermédiaire .
Retour true
/false
Ceci est utilisé dans certaines API plus anciennes, principalement de style C. Les inconvénients sont évidents, vous n'avez aucune idée de ce qui s'est mal passé. PHP le fait assez souvent, conduisant à du code comme celui-ci:
if (xyz_parse($data) === FALSE)
$error = xyz_last_error();
Dans des contextes multithread, c'est encore pire.
Lancer des exceptions (cochées)
C'est une belle façon de procéder. À certains moments, vous pouvez vous attendre à un échec. Java le fait avec des sockets. L'hypothèse de base est qu'un appel doit réussir, mais tout le monde sait que certaines opérations peuvent échouer. Les connexions de socket en font partie. Ainsi, l'appelant est obligé de gérer l'échec. C'est un design agréable, car il garantit que l'appelant gère réellement l'échec et lui donne un moyen élégant de gérer l'échec.
Renvoyer l'objet de résultat
C'est une autre belle façon de gérer cela. Son souvent utilisé pour l'analyse ou tout simplement les choses qui doivent être validées.
ValidationResult result = parser.validate(data);
if (result.isValid())
// business logic
else
error = result.getvalidationError();
Belle logique propre pour l'appelant également.
Il y a un peu de débat quand utiliser le deuxième cas et quand utiliser le troisième. Certaines personnes croient que les exceptions doivent être exceptionnelles et que vous ne devez pas concevoir avec la possibilité d'exceptions à l'esprit, et utiliserez presque toujours la troisième option. C'est bien. Mais nous avons vérifié les exceptions en Java, donc je ne vois aucune raison de ne pas les utiliser. J'utilise des expetions vérifiées lorsque l'hypothèse de base est que l'appel doit réussir (comme l'utilisation d'une socket), mais l'échec est possible, et j'utilise la troisième option lorsque son très peu clair si l'appel doit réussir (comme la validation des données). Mais il y a des opinions différentes à ce sujet.
Dans votre cas, j'irais avec void
+ Exception
. Vous vous attendez à ce que le téléchargement du fichier réussisse, et quand ce n'est pas le cas, c'est exceptionnel. Mais l'appelant est obligé de gérer ce mode d'échec et vous pouvez renvoyer une exception qui décrit correctement le type d'erreur qui s'est produite.