Suite à cette discussion, je regardais comment le cas est géré en Java (je ne connais pas C++), et c’est intéressant parce que les deux méthodes génériques pour calculer le maximum d’un ensemble ont deux fonctionnements différents de par leur API, ce qui rejoint bien le propos de barmic ci-dessus.
L’API Collections (Java 1.2 et plus) a une méthode qui permet de calculer le maximum d’une collection d’éléments comparables. Si la collection fournie est vide, ça lance une NoSuchElementException (qui est une exception non-checkée, donc qu’il n’est pas obligatoire de gérer dans les couches supérieures). De plus, le code ne compilera pas si les éléments ne sont pas comparables, et renverra une ClassCastException (non-checkée) si on essaie de comparer des choux et des carottes.
Java depuis Java 8 contient aussi une API de streams, qui déteste les exceptions – le dédoublement du flux d’exécution est à peu près incompatible avec le concept même des streams. Donc il a fallu trouver une solution alternative.
Dans le cas des streams, le calcul du maximum renvoie un Optional, à charge de l’appelant de vérifier si cette valeur optionnelle est vide ou non. On peut facilement récupérer le comportement à exceptions en faisant : myStream.max().orElseThrow(NoSuchElementException::new) (là encore au choix de l’appelant).
Concernant Java, il y a un paradoxe assez étonnant qui fait que d’une part à peu près tout le monde considère que les checked exceptions sont une erreur de conception fondamentale du langage, mais en même temps que tout le monde les utilise. Même si depuis Java 8 et l’utilisation de plus en plus massive des streams, ce deuxième point est de moins en moins vrai.
[^] # Re: Juste mon point de vue
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 5. Dernière modification le 08 août 2022 à 12:48.
Suite à cette discussion, je regardais comment le cas est géré en Java (je ne connais pas C++), et c’est intéressant parce que les deux méthodes génériques pour calculer le maximum d’un ensemble ont deux fonctionnements différents de par leur API, ce qui rejoint bien le propos de barmic ci-dessus.
L’API
Collections(Java 1.2 et plus) a une méthode qui permet de calculer le maximum d’une collection d’éléments comparables. Si la collection fournie est vide, ça lance uneNoSuchElementException(qui est une exception non-checkée, donc qu’il n’est pas obligatoire de gérer dans les couches supérieures). De plus, le code ne compilera pas si les éléments ne sont pas comparables, et renverra uneClassCastException(non-checkée) si on essaie de comparer des choux et des carottes.Java depuis Java 8 contient aussi une API de streams, qui déteste les exceptions – le dédoublement du flux d’exécution est à peu près incompatible avec le concept même des streams. Donc il a fallu trouver une solution alternative.
Dans le cas des streams, le calcul du maximum renvoie un
Optional, à charge de l’appelant de vérifier si cette valeur optionnelle est vide ou non. On peut facilement récupérer le comportement à exceptions en faisant :myStream.max().orElseThrow(NoSuchElementException::new)(là encore au choix de l’appelant).Concernant Java, il y a un paradoxe assez étonnant qui fait que d’une part à peu près tout le monde considère que les checked exceptions sont une erreur de conception fondamentale du langage, mais en même temps que tout le monde les utilise. Même si depuis Java 8 et l’utilisation de plus en plus massive des streams, ce deuxième point est de moins en moins vrai.
La connaissance libre : https://zestedesavoir.com