L'approche par itérateurs de la bibliothèque standard permet de gérer très élégamment le problème des cas particuliers, c'est impeccable et permet effectivement un grand contrôle: lancer une exception, retourner un optionnel, renvoyer une valeur par défaut...
Mais dans ma question d'entretien, l'on demande expressément à renvoyer "le plus grand élément", pas un itérateur. Or, mathématiquement, le plus grand élément d'un ensemble vide, ça n'a pas de sens. Donc, renvoyer une exception est raisonnable.
Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).
Maintenant, le candidat qui me dit que cela dépend de la manière dont l'équipe a décidé de gérer les erreurs, et qui peut vraiment comparer les avantages et les inconvénients des différentes méthodes, je suis ravi ! C'est quelqu'un qui réfléchit, et qui s'adapte au contexte du problème.
Je te rejoins sur cette histoire de 0.1% qui me semble bien trop élevé. Je fais régulièrement tourner gdb avec un "catch throw" dans nos binaires, et je vois bien que dans les faits, quand tout se passe bien, l'on ne jette pas une seule exception, ou alors à la rigueur à l'initialisation parce qu'il y a toujours des choses à jeter dans nos jeux de données. En revanche, quand ça se passe mal, on nettoie tout bien, on a de belles erreurs à peu près claires, et l'on peut continuer le traitement.
[^] # Re: Pas de fumée sans feu
Posté par small_duck (site web personnel) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 6.
L'approche par itérateurs de la bibliothèque standard permet de gérer très élégamment le problème des cas particuliers, c'est impeccable et permet effectivement un grand contrôle: lancer une exception, retourner un optionnel, renvoyer une valeur par défaut...
Mais dans ma question d'entretien, l'on demande expressément à renvoyer "le plus grand élément", pas un itérateur. Or, mathématiquement, le plus grand élément d'un ensemble vide, ça n'a pas de sens. Donc, renvoyer une exception est raisonnable.
Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).
Maintenant, le candidat qui me dit que cela dépend de la manière dont l'équipe a décidé de gérer les erreurs, et qui peut vraiment comparer les avantages et les inconvénients des différentes méthodes, je suis ravi ! C'est quelqu'un qui réfléchit, et qui s'adapte au contexte du problème.
Je te rejoins sur cette histoire de 0.1% qui me semble bien trop élevé. Je fais régulièrement tourner gdb avec un "catch throw" dans nos binaires, et je vois bien que dans les faits, quand tout se passe bien, l'on ne jette pas une seule exception, ou alors à la rigueur à l'initialisation parce qu'il y a toujours des choses à jeter dans nos jeux de données. En revanche, quand ça se passe mal, on nettoie tout bien, on a de belles erreurs à peu près claires, et l'on peut continuer le traitement.