Questions de base sur les exceptions

Bonjour.

Je découvre en ce moment la gestion des erreurs en C++ et j'ai quelques petites questions. Je suis en train de faire une classe pour lire/écrire un type de fichier binaires perso, et j'aimerai bien gérer les erreurs proprement quand il y a un problème de lecture/écriture.

Aussi j'ai quelques petites question :
1) Y-a-t-il une erreur standard déjà prête pour les erreurs d'IO ?
2) Comment faire pour que le code crashe si jamais il y a eu une erreur d'IO ?
3) Que se passe-t-il si une erreur lancée par un throw() n'est jamais rattrapée par un catch() ?
4) Peut-on faire des throw() sans bloc try(), et si oui, dans quel contexte ?

Et plus spécifiquement :
Actuellement, toutes les fonctions de ma classe retournent une variable "bool ok" pour indiquer que l'opération d'IO s'est bien passée. Si je veux que le code crashe "proprement" si jamais l'opération d'IO s'est mal passée que dois-je rajouter dans mes fonctions avant le "return ok;" ?

Merci beaucoup ;)

Citation:

---

Envoyé par Kaluza

1) Y-a-t-il une erreur standard déjà prête pour les erreurs d'IO ?

---

les exceptions standard sont dans stdexcept. Choisis en une, ou alors dérives en toi même une nouvelle de exception

Citation:

---

Envoyé par Kaluza

2) Comment faire pour que le code crashe si jamais il y a eu une erreur d'IO ?
3) Que se passe-t-il si une erreur lancée par un throw() n'est jamais rattrapée par un catch() ?
4) Peut-on faire des throw() sans bloc try(), et si oui, dans quel contexte ?

---

Faire "crasher" ton code c'est simple : *((int*)(0))++; 8-) Mais je suppose que c'est pas le but, ce que tu veux, c'est que ton programme se termine, si possible proprement, et si possible avec un message d'erreur.
Pour ca il suffit de lancer une exception, et de ne jamais la rattraper dans un catch qui va bien (ou même sans bloc try). L'exception "sortira" alors de main, et le programme se terminera.
Lancer une exception sans try, ou lancer une exception sans un catch approprié ont le même effet, et c'est tout a fait possible (testé par un sagouin des exceptions !:aie:). Tu as a lors un joli message d'erreur dans la console (sous linux au moins) avec le message de l'exception.

Citation:

---

Envoyé par Kaluza

Et plus spécifiquement :
Actuellement, toutes les fonctions de ma classe retournent une variable "bool ok" pour indiquer que l'opération d'IO s'est bien passée. Si je veux que le code crashe "proprement" si jamais l'opération d'IO s'est mal passée que dois-je rajouter dans mes fonctions avant le "return ok;" ?

---

Quand une exception est lancée, elle descend le stack proprement, c'est a dire en appelant les destructeurs de toutes les variables sur le stack au fur et a mesure qu'elle descend. Tu peux utiliser ca pour essayer de fermer ton programme le plus proprement possible.
Sinon les OS de nos jours desalouent automatiquement la mémoire quand le programme quitte, donc si tu veux fermer ton programme, faire ca proprement n'est a priori pas important.
Par contre, pour les accès à une ressource matérielle (tu nous parles d'IO), ca peut valoir le coup de fermer proprement les interfaces d'accès.

Citation:

---

Envoyé par Kaluza

Bonjour.

Je découvre en ce moment la gestion des erreurs en C++ et j'ai quelques petites questions. Je suis en train de faire une classe pour lire/écrire un type de fichier binaires perso, et j'aimerai bien gérer les erreurs proprement quand il y a un problème de lecture/écriture.

Aussi j'ai quelques petites question :
1) Y-a-t-il une erreur standard déjà prête pour les erreurs d'IO ?

---

Non, mais tu peux dériver directement de std::runtime_error pour les erreur de lecture ou de std::invalid_argument si le fichier que tu essaye d'ouvrir n'existe pas ;)

Citation:

---

2) Comment faire pour que le code crashe si jamais il y a eu une erreur d'IO ?

---

La solution crade : tu ne place aucun try catch dans ton code... Si on sort de main sans avoir récupéré une erreur, le programme plante en disant qu'il y a une exception qui n'est pas gérée ;)

La solution propre consiste à faire en sorte de correctement nettoyer le tout dans un try(...) (qui va récupérer toutes les exceptions qui n'ont pas été récupérée par d'autres blocs catch), d'afficher éventuellement un message d'erreur, de veiller à libérer toutes les ressources et de quitter (avec un exit(1) ) ;)

Citation:

---

3) Que se passe-t-il si une erreur lancée par un throw() n'est jamais rattrapée par un catch() ?

---

Le programme "plante", tout simplement, et tout brutalement ;)

Citation:

---

4) Peut-on faire des throw() sans bloc try(), et si oui, dans quel contexte ?

---

Ce n'est pas vraiment conseillé (l'idéal étant qu'il y ait au minimum un try{} catch(...) dans la fonction main pour faire ce que j'ai dit plus haut), car, autrement, le programme plante durement, sans donner la chance de faire quoi que ce soit ;)

Citation:

---

Et plus spécifiquement :
Actuellement, toutes les fonctions de ma classe retournent une variable "bool ok" pour indiquer que l'opération d'IO s'est bien passée. Si je veux que le code crashe "proprement" si jamais l'opération d'IO s'est mal passée que dois-je rajouter dans mes fonctions avant le "return ok;" ?

---

Cela peut dépendre énormément de ce que tu veux faire...

Typiquement, une erreur transporte avec elle le contexte dans lequel elle est survenue, de manière à donner l'occasion d'y remédier "par ailleurs".

Selon l'endroit où le contexte est le plus favorable (comprends : selon l'endroit où tu disposeras des informations susceptibles de te donner un indice quant à la manière de résoudre ton erreur), tu peux soit carrément lancer une exception avant le return, soit attendre de récupérer la valeur (false) renvoyée par ta fonction avant de lancer l'exception...

Le tout étant toujours de savoir si tu as la possibilité de remédier à ton erreur (et les informations qui te permettront de le faire)...

Un simple exemple:

Si tu essaye d'ouvrir ton fichier, mais que le nom (transmis en paramètre) est "fichier.bin", et que le vrai nom de fichier doit etre "fichier.bat", tu peux lancer ton exception directement et faire en sorte qu'elle contienne une information du genre de "impossible d'ouvrir le fichier "fichier.bin".

Ce sera alors à l'utilisateur de fournir le nom de fichier correct.

Si, par contre, tu obtiens une erreur au moment de lire une donnée, tu peux décider de lancer l'exception au moment meme, mais tu peux aussi attendre d'être revenu dans la fonction qui a appelé celle qui provoque l'erreur pour fournir l'information de ce qui avait déjà été lu avant que cela ne foire ;)

Merci beaucoup pour vos réponses très claires :ccool:
J'ai aussi fait quelques tests entre temps et j'ai mieux compris comment cela fonctionnait.

Je pense que ma classe va juste lancer des exceptions si jamais ça se passe mal, charge à celui qui l'utilise de faire des try/catch. C'est une classe pour lire/écrire des fichiers fortran binaires, pour jongler avec l'endianness et autres joyeusetés donc si jamais un truc semble louche dans le fichier, je pense faire juste un throw et laisser les classes de plus haut niveau se débrouiller avec.

Merci encore ;)

Citation:

---

Envoyé par Kaluza

pour jongler avec l'endianness et autres joyeusetés donc si jamais un truc semble louche dans le fichier, je pense faire juste un throw et laisser les classes de plus haut niveau se débrouiller avec.

Merci encore ;)

---

C'est, effectivement, la manière dont cela se passe généralement: on lance l'exception à l'endroit où elle se produit, mais la gestion de cette exception se fait généralement plus "haut" dans le programme ;)