Et là les problèmes vont commencer avec le try catch…
Je ne pense pas que retarder le problème soit une bonne façon de gérer les try catch. Personnellement en même temps que je réfléchis aux paramètres et au retour d'une fonction, je me pose la question des exceptions (de quoi à besoin ma fonction ? à quoi elle sert/qu'est ce qu'elle retourne ? pourquoi/comment elle peut planter ?). Il me semble que c'est comme ça que ça reste logique. Ensuite l'architecture d'une application peut beaucoup aider (dans une archi à composant les composants ne doivent pas se vautrer salement déjà).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage
Posté par barmic . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Je ne pense pas que retarder le problème soit une bonne façon de gérer les try catch. Personnellement en même temps que je réfléchis aux paramètres et au retour d'une fonction, je me pose la question des exceptions (de quoi à besoin ma fonction ? à quoi elle sert/qu'est ce qu'elle retourne ? pourquoi/comment elle peut planter ?). Il me semble que c'est comme ça que ça reste logique. Ensuite l'architecture d'une application peut beaucoup aider (dans une archi à composant les composants ne doivent pas se vautrer salement déjà).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)