Je ne suis pas d'accord :
1) méthodologiquement, les exceptions sont destinées aux erreurs que l'on ne maitrise pas, une condition anormale : réseau indisponible, saturation disque/mémoire, faute matérielle ... générer une exception pour une impossibilité mathématique me semble déplacé.
2) algorithmiquement, on peut s'en sortir comme avec la méthode "search" qui renvoie vrai ou faux si un élément existe dans un ensemble. si l'élément existe, la éthode "last_found" renvoit cet élément, sans avoir à relancer de recherche. Il existe une méthode d'inversion de matrice qui utilise le calcul de déterminant. Il suffirait de stocker le déterminant calculé lors de l'appel de est_inversible pour s'en servir lors de l'inversion de matrice.
J'avoue ne pas avoir une grande expérience dans le développement concret d'applications, mais ma méthode me semble plus propre et plus proche de l'esprit des contrats.
[^] # Re: Quelques "coquilles"
Posté par Guillaume Vauvert . En réponse à la dépêche Sortie de Hercule la version 2 du compilateur SmartEiffel. Évalué à 3.
1) méthodologiquement, les exceptions sont destinées aux erreurs que l'on ne maitrise pas, une condition anormale : réseau indisponible, saturation disque/mémoire, faute matérielle ... générer une exception pour une impossibilité mathématique me semble déplacé.
2) algorithmiquement, on peut s'en sortir comme avec la méthode "search" qui renvoie vrai ou faux si un élément existe dans un ensemble. si l'élément existe, la éthode "last_found" renvoit cet élément, sans avoir à relancer de recherche. Il existe une méthode d'inversion de matrice qui utilise le calcul de déterminant. Il suffirait de stocker le déterminant calculé lors de l'appel de est_inversible pour s'en servir lors de l'inversion de matrice.
J'avoue ne pas avoir une grande expérience dans le développement concret d'applications, mais ma méthode me semble plus propre et plus proche de l'esprit des contrats.