Bonjour, je débute et au cours d'un TP (openclassroom) je dois par exemple:
- Lire/Ecrire dans un fichier

Pour lire le fichier, je me suis dis que le fichier peut ne pas exister et donc lever une exception FileNotFoundError
Ainsi je
try: lire le fichier
except: créer le fichier # puisqu'il n'existe pas

Hors dans la correction du TP on procède tout simplement ainsi:
if os.path.exists

Du coup, quand dois-je utiliser les exceptions ?
- Si et seulement si il n'existe pas de moyen de vérifier l'information par Python ou un de ses modules ?
- Si et seulement si je dois traiter des données entrée par un utilisateur ?

Bref j'en comprends bien l'utilité mais j'ai du mal à comprendre QUAND l'utiliser, car je peux toujours vérifier mon code jusque là et contrôler les données sans avoir à passer par des exceptions mais des if. Puis placer des if partout est plus jolie que des try except.

Merci

Edit: Je viens de tomber d'ailleurs sur une autre source, qui dit que pour vérifier l’existence d'un fichier c'est bien mieux de passer par les exceptions car avec des if, il faudrait
Vérifier que le fichier existe.
Vérifier que le fichier est un fichier et non un dossier.
Vérifier que j’ai les permissions d’écrire sur le fichier.
Vérifier que j’ai les permissions de traverser les dossiers parents.
Vérifier que personne n’a ouvert le fichier en écriture avant.

Tout simplement avec un except IOError, OSError

Du coup je reste perdu... Je ne sais pas quoi privilégier et qu'elle est la façon normale de procéder.

Egalement, pourquoi créer soit même une exception (raise) pour la traiter ensuite, alors qu'on peut la traiter desuite ?

up

La question m’intéresse aussi, histoire d'optimiser un peu mon code
 
Pour l'instant je me contente d'un :
 

J'ai continué à potasser la question, à priori il n'y a rien de défini... Souvent on se passe des exceptions car il existe un raccourci ce qui rend le code moins verbeux...
 
Bref je trouve ça assez pompeux comme raison, contourner un système créer POUR, simplement pour que ce soit moins lourd. Ça me rappel le PHP.
 
Si un pro pouvait partageait son avis...

Moi je ne passe pas des exceptions, puis comme tout mes chargement de fichier, que ce soit, text, xml, ou pickle, ils sont tous inclus dans des fonction je peux me permettre de faire des tests. Puis tu gagne un temps fou quand tu debug de savoir directement d’où provient le probleme
 
J'utilise aussi " os.path.exists " ainsi que isdir, ou isfile assez fréquemment. Quand j'importe un module perso qui traite des fichier XML je fais en premier des tests sur le "chemin/fichier"  
 
 

 
 
puis lors du chargement du fichier j'utilise les exceptions

En fait pour répondre à ta question : Quand privilégier les exceptions ?
 
Je ne vois aucun intérêt à ne pas les utiliser.
 
Même quand j'importe des modules :  
 

C'est aussi ce que j'aurais fais. Mais je souhaite intégrer les exceptions dans mon travail. Du coup c'est surtout une question d'idéologie (c'est peut être pas le bon mot) plus que de pratique je trouve.
 
Je prends par exemple l'utilité clair de l'exception forms.ValidationError lors de la validation d'un formulaire Django.
Lever cette exception fait que django renvoi "tout seul" le formulaire, et il affiche "tout seul" où se trouve l'erreur, etc...
Vérification et renvoi qu'on peut très bien faire par soit même (comme tout en fait). Du coup c'est explicite que lever l'exception est la bonne pratique dans ce cas.
 
Bref je ne sais donc toujours pas la philosophie des exceptions et leur place.
 
A la limite, comme tu l'as dis, on utilise l'exception et si on veut plus de précision on gère l'erreur soit même. Ce qui ferait que les exceptions ne seraient pas si utiles que ça (puisqu'on peut tout faire soit même). Je ne vois que ça

Un avantage important dans certains cas, particulièrement pour les fichiers, c'est qu'en passant par
les exceptions tu évites d'avoir des problèmes si le fichier apparaît ou disparaît entre le moment où
tu testes son existence et le moment où tu l'ouvres.

C'est pas de bol quand ça arrive, la fenêtre de temps est petite, mais ça arrive et le résultat est assez
catastrophique si justement tu n'as aucun endroit pour attraper l'exception, ton programme s'arrête
ou ta page web renvoie une 500.

Après il faut l'attraper au bon endroit, pas forcément exactement là où elle apparaît, plutôt là où tu
peux la traiter: réessayer, afficher un message d'erreur, annuler l'effet des opérations à moitié
commencées, traduire l'exception par une autre de plus haut niveau.

Par exemple: un fichier python est absent ou a une erreur de syntaxe, ça correspond à au moins
deux exceptions différentes, mais le bout de code qui s'occupe d'importer les modules python les
attrape et les englobe dans un ImportError avec un message explicatif, parce que ce qui compte pour
le mec qui importe des modules c'est de savoir si ça réussit ou pas, il a pas à savoir à l'avance les
250 causes possibles d'exception improbables, et prévoir 250 except différents, il attrape ImportError
et en cas de souci il peut lire le message ou la série d'exceptions qui a causé cette exception).

Pour le cas des fichiers, s'il y a de l'interface utilisateur, ça arrive aussi d'avoir le "if" *et* la gestion
d'exceptions, le "if" est utilisé pour dire à l'utilisateur qu'il s'est planté dans son chemin de fichier
et qu'il faut qu'il le change, alors que la gestion d'exception est là pour la robustesse (par rapport
au cas expliqué au début). Par exemples dans certaines bases de code, en cas d'erreur à la lecture
d'un fichier, on va ré-essayer 2-3 fois de le ré-ouvrir avant d'échouer et de remonter l'erreur plus
haut, à cause des antivirus ou des générateurs de preview qui bloquent le fichier pendant un court
laps de temps, ça vaut le coup de patienter un peu. Après, tous les programmes n'ont pas forcément
besoin d'une telle robustesse, y'a souvent des trucs plus prioritaires à peaufiner avant.

Entre les styles EAFP et LBYL, je préfère le premier pour la raison qu'avec LBYL, le même test est fait deux fois: une fois dans ton code et une deuxième fois par l’implémentation de python.