C++Talk.NET

Aurélien REGAT-BARREL · Guest

Bonjour à tous,
Si vous avez lu le thread "[TORDU] Exception dans un destructeur, oui
mais..." vous savez que je suis en train de réfléchir à une meilleur gestion
des erreurs dans mon programme. Le critère numéro un est la simplicité
d'utilisation, pour encourager le programmeur à l"utiliser.
Le but est de simplifier au maximum un tel bloc de vérification:

int value = ...;
if ( value >= 10 )
{
std::ostringstream oss;
oss << "La valeur n'est pas un chiffre : " << value;
throw std::runtime_error( oss.str() );
}

j'étais parti dans un truc de ce genre:

verify( value < 10 ) << "La valeur n'est pas un chiffre : " << value;

Mais l'implémentation n'est pas top (exception lancée dans un destructeur),
et finalement je trouve ça moyennement explicite.

Après réflexion, je me suis dit que ce qui était le plus important en fin de
compte c'était de garder une trace des valeurs erronées. Le reste, à partir
du moment où on a l'emplacement dans le fichier on retrouve tout.
Alors voici ma nouvelle idée:

// la valeur doit être un chiffre
verify( value ) < 10;

verify() construit et renvoie un Verifier et c'est l'opérateur == de ce
dernier qui fait le test et lève ou non l'exception.

template class Verifier
{
public:
Verifier( const T & p1 ) : p1_( p1 ) {}

void operator == ( const T & p2 )
{
if ( ! ( this->p1_ == p2 ) )
{
std::ostringstream oss;
oss << "Verification failed with "
<< this->p1_ << " == " << p2;
throw std::runtime_error( oss.str() );
}
}

private:
T p1_;
};

template Verifier<T> verify( const T & t )
{
return Verifier<T>( t );
}

Je sais que boost a un truc pour simplifier la déclaration des opérateurs.
Ne connaissant pas la bête, je me suis contenté d'une macro pour simplifier
la tâche:

template <typename T>
class Verifier
{
public:
Verifier( const T & p1 ) : p1_( p1 ) {}

#define OPERATOR(op)
void operator op ( const T & p2 )
{
if ( ! ( this->p1_ op p2 ) )
{
std::ostringstream oss;
oss << "Verification failed with "
<< this->p1_ << " " #op " " << p2;
throw std::runtime_error( oss.str() );
}
}

OPERATOR( == )
OPERATOR( < )
OPERATOR( > )
OPERATOR( != )
OPERATOR( >= )
OPERATOR( <= )

#undef OPERATOR

private:
T p1_;
};

les opérateurs renvoient void, c'est pas innocent c'est pour empêcher de les
utiliser dans un autre contexte, je sais pas trop ce que ça ferait.

Jusque là j'aimerais avoir votre avis.

Mais attention j'ai l'esprit un peu tordu et ça va plus loin. Allons-y pour
l'usine à gaz. Moyennant une petite macro verify() qui permet de connaitre
le fichier & la ligne où on se situe :

#define verify(x) Verify( x, __FILE__, __LINE__ )

on peut imaginer que Verify initialiserait l'objet Verifier afin que ce
dernier localise l'emplacement de l'erreur. Comme assert() en fait. Sauf
que, j'ai parlé d'usine à gaz....

- Imaginons qu'en cas d'échec Verifier construise un code d'erreur qui
permette d'identifier le fichier et la ligne de l'échec.
- Imaginons qu'un stupide logiciel / script d'extraction de commentaires
génère un gros fichier qui contienne tous les commentaires situés sur la
même ligne ou une ligne au dessus d'un appel à verify()
- et imaginons enfin que ce fichier est structuré de manière à facilement
retrouver le commentaire "associé" à ce couple erreur (fichier - ligne)

eh ben dans un tel cas on pourrai obtenir en message d'erreur le commentaire
associé au verify() qui a échoué, et écrire des commentaires ferait partie
de la procédure de gestion des erreurs. Ces commentaires servent aussi à
documenter le projet...
Et on peut imaginer que le fichier résultat puisse être traduit par la suite
afin d'offrir des messages d'erreurs dans la langue que l'on veut.
Que pensez-vous de cette approche ?

--
Aurélien REGAT-BARREL

Loïc Joly · Guest

Aurélien REGAT-BARREL wrote:

drkm · Guest

Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> writes:

Aurelien REGAT-BARREL · Guest

Olivier Azeau · Guest

Aurélien REGAT-BARREL wrote:

Olivier Azeau · Guest

drkm wrote:

Gabriel Dos Reis · Guest

Olivier Azeau <john (AT) doe (DOT) com> writes:

SerGioGio · Guest

Bonjour,

Je préférais de loin ton idée précédente.
verify(version != 1) << "incorrect file version: " << version;

1. Maintenant, du point de vue de l'implementation, on ne peut a priori pas
lancer d'exception dans un destructeur...
mais par contre on peut ecrire l'esprit tranquile:

preverif( verify(version != 1) << "incorrect file version: " << version );

ici, verify construit un objet avec la condition evaluee et le message
d'erreur.
preverif est une fonction qui si la condition est false throw une exception.

2. grace aux joies de la precedence des operateurs, on peut transformer
cette expression en:

preverif() | verify(version != 1) << "incorrect file version: " << version;

Cette fois, preverif() est un objet qui a une fonction membre operator|.
operator| a une precedence moins eleve que << donc c'est << qui est evalué
en premier.

3. enfin une petite macro:

#define verif(a) preverif() | verify(a)

et on peut écrire:
verify(version != 1) << "incorrect file version: " << version;

voici le source complet:

struct verify
{
bool m_b;
std::ostringstream m_stream;
verify(bool a_b) : m_b(a_b) {}
template {
m_stream << a_t;
return *this;
}
};

struct preverif
{
void operator| (const verify& a_verif)
{
if (!a_verif.m_b) throw std::runtime_error(a_verif.m_stream.str());
}
};

#define verif(a) preverif() | verify(a)

SerGioGio

"Aurélien REGAT-BARREL" message de news:41eceddd$0$25762$626a14ce (AT) news (DOT) free.fr...

SerGioGio · Guest

Il y a toujours plus simple, et moins problématique, en utilisant
stringstream.

struct verify
{
bool m_b;
verify(bool a_b) : m_b(a_b) { }
void operator| (const std::ostream& a_stream)
{
std::istreambuf_iterator<char> beg(a_stream.rdbuf());
std::istreambuf_iterator<char> end;
if (!m_b) throw std::runtime_error(std::string(beg, end));
}
};
#define verif(a) verify(a) | std::stringstream() << std::flush << __FILE__
<< "(" << __LINE__ << ") "

L'appel à flush est nécéssaire, car par exemple, aussi surprenant que ça
puisse paraitre,
std::stringstream() << "hello world" appelle la fonction membre operator<<
(void* ) au lieu de la fonction globale operator<<(std::ostream&, const
char*) comme on aurait pu s'y attendre.
D'après ce que j'ai compris, la raison est que on ne peut pas lier un object
temporaire à une référence non-const, or std::stringstream() est un
temporaire, std::ostream& est une référence non-const, donc la fonction
globale operator<<(std::ostream&, const char*) est disqualifiée...
Par contre, on peut toujours appeler une fonction membre d'un temporaire, et
cette fonction membre est autorisée à renvoyer une référence non-const sur
l'objet, d'où le flush...

Donc la macro est au minimum:
#define verif(a) verify(a) | std::stringstream() << std::flush

SerGioGio

"SerGioGio" news:41edec7a$1 (AT) news (DOT) starhub.net.sg...

Aurélien REGAT-BARREL · Guest

Aurélien REGAT-BARREL · Guest

Ah, ah, ah... Je crois que je le tiens là. Suite à vos remarques, j'ai eu
l'idée de déplacer le problème.

Au départ:

verify( a != b ) << "erreur";

puis j'ai pensé à quelque chose comme :

verify( a != b ) = msg() << "erreur";

Et puis j'ai essayé de déplacer le test:

verify() = msg( a != b ) << "erreur";

msg() renvoie un "flux conditionnel" qui en fonction du test donné en
paramètre va s'initialiser ou non (pas de pénalité de performance à
construire un message d'erreur s'il n'y a pas d'erreur).
Le flux résultant sert à initialiser un objet Verifier renvoyé par verify().
L'opérateur = de ce dernier utilise la condition conservée dans le flux reçu
pour lever une exception ou non. On mélange le tout dans une macro, et voici
ce que ça donne:

class cond_ostream // conditionnal ostream
{
public:
// ctor: descriptif de la condition, sa valeur
// ex: cond_ostream( "10 == 10", true );
cond_ostream( const char * CondStr, bool CondResult )
{
this->do_throw_ = !CondResult;
if ( this->do_throw_ )
{
this->oss_ << "Echec du test '"
<< CondStr << "' : ";
}
}

template cond_ostream & operator << ( const T & t )
{
if ( this->do_throw_ )
{
this->oss_ << t;
}
return *this;
}

bool do_throw() const
{
return this->do_throw_;
}

std::string err_msg() const
{
return this->oss_.str();
}

private:
std::ostringstream oss_;
bool do_throw_;
};

struct Verifier
{
// throw runtime_error si le flux reçu le demande
void operator = ( const cond_ostream & o )
{
if ( o.do_throw() )
{
throw std::runtime_error( o.err_msg() );
}
}
};

#define verify( x ) Verifier() = cond_ostream( #x, x )

et ça s'utilise comme ça:

int main()
{
try
{
verify( 10 == 10 ); // sans message d'erreur, ça marche
verify( 10 == 9 ); // << "erreur";
}
catch ( const std::exception & e )
{
std::cerr << e.what() << 'n';
}
}

on pourrait envisager d'enrichir un peu la macro et le flux / le Verifier
pour tracer __FILE__ et __LINE__.

Qu'en pensez-vous ?

--
Aurélien REGAT-BARREL

--
Aurélien REGAT-BARREL
"Aurélien REGAT-BARREL" message de news:41eceddd$0$25762$626a14ce (AT) news (DOT) free.fr...

Aurélien REGAT-BARREL · Guest

Matthieu Moy · Guest

"Aurélien REGAT-BARREL" <nospam-aregatba (AT) yahoo (DOT) fr.invalid> writes:

Olivier Azeau · Guest

Matthieu Moy wrote:

Aurélien REGAT-BARREL · Guest