Bonjour,
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
Bonjour,
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
Bonjour,
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
Le contenu du what() dépend de l'implémentation de la STL.
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
Le contenu du what() dépend de l'implémentation de la STL.
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
Le contenu du what() dépend de l'implémentation de la STL.
Parmi les quatre auxquels j'ai accès, j'ai :
"basic_ios::clear" (g++),
"iostream object has failbit set" (Sun CC/Rogue Wave),
"ios failure" (Sun CC/STL port), and
"ios_base::failbit set" (VC++/Dinkumware).
J'ai comme un petit soupçon qu'il voulait plus d'information que
ça.
Parmi les quatre auxquels j'ai accès, j'ai :
"basic_ios::clear" (g++),
"iostream object has failbit set" (Sun CC/Rogue Wave),
"ios failure" (Sun CC/STL port), and
"ios_base::failbit set" (VC++/Dinkumware).
J'ai comme un petit soupçon qu'il voulait plus d'information que
ça.
Parmi les quatre auxquels j'ai accès, j'ai :
"basic_ios::clear" (g++),
"iostream object has failbit set" (Sun CC/Rogue Wave),
"ios failure" (Sun CC/STL port), and
"ios_base::failbit set" (VC++/Dinkumware).
J'ai comme un petit soupçon qu'il voulait plus d'information que
ça.
On May 14, 1:32 pm, Marc Boyer
wrote:je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
Pourquoi pas ?
Formellement, la situation est exactement pareille qu'en C. La
fonction dit s'il a réussi ou non, mais la norme ne prévoit
aucune indication en ce qui concerne le pourquoi d'un échec.
Tout au plus permet-elle à l'implémentation de modifier errno,
sans pour autant l'exiger ni spécifier des valeurs qu'errno
pourrait éventuellement prendre.
Dans la pratique, sur des plateformes Unix et semblable, et
filebuf::open et fopen vont se réposer sur la fonction Posix
open, et c'est elle qui positionne en fait errno en cas
d'erreur. En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné. (En renvanche, je
serais très étonné que filebuf::open et fopen se comportent de
manière différente, quelque soit la plateforme.)
On May 14, 1:32 pm, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
Pourquoi pas ?
Formellement, la situation est exactement pareille qu'en C. La
fonction dit s'il a réussi ou non, mais la norme ne prévoit
aucune indication en ce qui concerne le pourquoi d'un échec.
Tout au plus permet-elle à l'implémentation de modifier errno,
sans pour autant l'exiger ni spécifier des valeurs qu'errno
pourrait éventuellement prendre.
Dans la pratique, sur des plateformes Unix et semblable, et
filebuf::open et fopen vont se réposer sur la fonction Posix
open, et c'est elle qui positionne en fait errno en cas
d'erreur. En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné. (En renvanche, je
serais très étonné que filebuf::open et fopen se comportent de
manière différente, quelque soit la plateforme.)
On May 14, 1:32 pm, Marc Boyer
wrote:je débute avec les fichiers, et je me demandais comment
on faisait pour avoir la cause de l'erreur.
Je fais un
ofstream f("toto.txt");
if (!f.is_open()){
cerr<<"Impossible d'ouvrir toto.txt "<<strerrno(errno)<<endl;
}
Mais est-ce bien la C++-attitude ?
Pourquoi pas ?
Formellement, la situation est exactement pareille qu'en C. La
fonction dit s'il a réussi ou non, mais la norme ne prévoit
aucune indication en ce qui concerne le pourquoi d'un échec.
Tout au plus permet-elle à l'implémentation de modifier errno,
sans pour autant l'exiger ni spécifier des valeurs qu'errno
pourrait éventuellement prendre.
Dans la pratique, sur des plateformes Unix et semblable, et
filebuf::open et fopen vont se réposer sur la fonction Posix
open, et c'est elle qui positionne en fait errno en cas
d'erreur. En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné. (En renvanche, je
serais très étonné que filebuf::open et fopen se comportent de
manière différente, quelque soit la plateforme.)
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture.
On May 14, 2:54 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture.
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture.
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
On May 14, 2:54 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné.
En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné.
En revanche, je n'ai malheureusement pas d'expérence
sur ce sujet sous Windows ; je ne saurais donc dire si c'est
aussi le cas là que errno soit positionné.
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
On May 14, 2:54 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
Je suis d'accord que, vu l'inutilité des messages, l'activation de
l'exception est superflu.
C'est dommage que l'exception lancée par open() n'inclue pas un champ
errno (à défaut d'avoir un message plus informatif).
Peut être dans ce cas, refaire un filebuf qui lance une exception
personnalisé en utilisant les fonctions POSIX.
On May 14, 2:54 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
Je suis d'accord que, vu l'inutilité des messages, l'activation de
l'exception est superflu.
C'est dommage que l'exception lancée par open() n'inclue pas un champ
errno (à défaut d'avoir un message plus informatif).
Peut être dans ce cas, refaire un filebuf qui lance une exception
personnalisé en utilisant les fonctions POSIX.
On May 14, 2:54 pm, Michael DOUBEZ wrote:En utilisant open() qui est susceptible de lancer une exception à
condition de l'avoir activer avant:
ofstream f;
// Lancer une exception si "failbit" ou "badbit" est levé
f.exceptions (ios::failbit | ios::badbit);
try
{// Open will throw on error
f.open ("toto.txt");}
catch (exception &e)
{
cerr << "Impossible d'ouvrir toto.txt : " << e.what () << endl;
}
C'est un peu tordu d'utiliser des exceptions dans ce cas-ci,
non ?
Je trouve aussi. Et il faudrait penser a nettoyer les drapeaux
d'exception apres l'ouverture, si on veut garder un comportement
"classique" des flux, au moins en lecture. Le code suivant
se termine par une exception, meme si le fichier est present:
Je suis d'accord que, vu l'inutilité des messages, l'activation de
l'exception est superflu.
C'est dommage que l'exception lancée par open() n'inclue pas un champ
errno (à défaut d'avoir un message plus informatif).
Peut être dans ce cas, refaire un filebuf qui lance une exception
personnalisé en utilisant les fonctions POSIX.