Définition d'une hiérarchie d'exceptions

La question que je me pose en fait est la suivante:
* A qui sont destinées les exceptions? Au concepteur de bibliothèque, à
l'utilisateur de la bibliothèque, ou au client final?

Par exemple, voici une fonction tirée de la bibliothèque (c'est une
fonction utilisée à l'intérieur de la bibilothèque, qui n'est pas
accessible à l'utilisateur)

//-------------------------------------------------------------------------
void OutputFileDVType2::ConnectToVideoDevice(CComPtr<IBaseFilter> &
pDevice)
{
assert(CheckInputDeviceIsDVCam() == true);

/* Check if the device is the smart tee filter or the real capture device
The process is different in case of the smart tee filter, because we must
use
Dshow::Func::GetPinCategory with NULL parameters on its pin, because the
output pins of the Smart Tee
don't support IEnumMediaTypes and IKsPropertySet. */

CComPtr<IPin> pPinDeviceOutput;

GUID deviceCateg;
if (FAILED(pDevice->GetClassID(&deviceCateg)))
{
//Exception
}

if (deviceCateg == CLSID_SmartTee)
DShow::Func::GetPin(pDevice,NULL,PINDIR_OUTPUT,NULL,pPinDeviceOutput);
else
DShow::Func::GetPin(pDevice,&MEDIATYPE_Interleaved,PINDIR_OUTPUT,
&PIN_CATEGORY_CAPTURE,pPinDeviceOutput);

if (pPinDeviceOutput == NULL)
{
//Exception
}

if (FAILED(Func::ConnectFilters(pGraph,pPinDeviceOutput,pDVSplit)))
{
//Exception
}

//Connect the DV Splitter to the AVI Mux (twice)
if (FAILED(Func::ConnectFilters(pGraph,pDVSplit,pFilter)))
{
//Exception
}

if (FAILED(Func::ConnectFilters(pGraph,pDVSplit,pFilter)))
{
//Exception
}
}

Je me rends compte en fait que les exceptions que je pourrais lancer ici
n'intéressent qu'une seule personne : Moi !! En effet elles me
permettraient de savoir où se trouve une erreur dans le code (Par exemple
quels sont les filtres que je tente de mettre en relation alors qu'ils ne
le devraient pas...)

Mais je me dis que ce pourrait être intéressant de les laisser, ce qui
permettrait à l'utilisateur de la bibliothèque ou à l'utilisateur final de
faire remonter des "codes d'erreur" lancés par les exceptions...




Pour moi écrire la bibliothèque et vérifier que ce que je fais est bon,
est-ce que des simples assert sont suffisants? Auquel cas le code précédent
deviendrait

//-------------------------------------------------------------------------
void OutputFileDVType2::ConnectToVideoDevice(CComPtr<IBaseFilter> &
pDevice)
{
assert(CheckInputDeviceIsDVCam() == true);

/* Check if the device is the smart tee filter or the real capture device
The process is different in case of the smart tee filter, because we must
use
Dshow::Func::GetPinCategory with NULL parameters on its pin, because the
output pins of the Smart Tee
don't support IEnumMediaTypes and IKsPropertySet. */

CComPtr<IPin> pPinDeviceOutput;

GUID deviceCateg;
assert(pDevice->GetClassID(&deviceCateg));

if (deviceCateg == CLSID_SmartTee)
DShow::Func::GetPin(pDevice,NULL,PINDIR_OUTPUT,NULL,pPinDeviceOutput);
else
DShow::Func::GetPin(pDevice,&MEDIATYPE_Interleaved,PINDIR_OUTPUT,
&PIN_CATEGORY_CAPTURE,pPinDeviceOutput);

assert(pPinDeviceOutput != NULL);

assert(Func::ConnectFilters(pGraph,pPinDeviceOutput,pDVSplit));

//Connect the DV Splitter to the AVI Mux (twice)
assert(Func::ConnectFilters(pGraph,pDVSplit,pFilter));

assert(Func::ConnectFilters(pGraph,pDVSplit,pFilter));
}


Et ne lancer des exceptions que lors des fonctions utilisées par
l'utilisateur de la bibliothèque?

Michael wrote:

Bonsoir à tous,

achevant l'écriture de ma bibliothèque servant à utiliser l'API DirectShow,
j'en arrive au sujet un peu brulant pour moi que sont les exceptions...

Arf ... c'est pas le bon moment pour penser à ça ... les exceptions,
c'est comme les const, c'est plus facile si tu le fais dès le début
(sinon tu risques de trouver ça inutilement pénible et de ne plus le
faire par la suite, ce qui serait dommage ...).

Je ne sais pas comment les implémenter correctement.

J'ai distingué trois types d'exception qui peuvent être levées:

1) Les exceptions qui surgissent pendant l'initialisation des modules et
qui interdisent l'utilisation du module (initialisation d'un filtre qui
échoue par exemple, ou bien tentative de connecter deux filtres qui ne
peuvent pas être mis en relation ensemble)

2) Les exceptions qui surgissent lors de l'utilisation d'un module, mais
qui n'entravent pas son fonctionnement (impossibilité de se déplacer dans
une vidéo manuellement par exemple, impossibilité d'extraire une image
d'une vidéo)

3) Les exceptions qui sont levées suite à une action de l'utilisateur du
programme final (Problème dans le choix d'un fichier par exemple (un ZIP au
lieu d'un AVI))


Les exceptions de la première catégorie sont plutôt destinés au programmeur
qui utilise la bibliothèque et n'aident en rien l'utilisateur du programme
final, puisqu'il ne pourra rien modifier.


Les exceptions de la deuxième catégorie peuvent être utiles à l'utilisateur
de la librairie et à l'utilisateur du programme


Enfin les exceptions de la dernière catégorie sont exclusivement destinées
à l'utilisateur du programme, afin qu'il change de fichier qui doit être lu
par exemple.



Bref toujours est-il que je ne sais pas comment m'y prendre...

Est-ce que je dois encadrer les fonctions susceptibles de lever une
exception par un try catch()? Lesquelles?

Pour ça y a de très bons remarques dans "Guru of the Week" :
http://www.gotw.ca/gotw/065.htm

En gros, gérer les exceptions, ce n'est que *peu* utiliser try/catch.
Pour les exceptions qui mettent ta bibliothèque dans un état pas
possible, en gros ton seul soucis sera de ne pas avoir de fuites de
mémoire et que tu libères bien les ressources, ce qui ne posera aucun
problème si tu n'utilises que des smart pointer et, plus généralement,
l'idiome de l'initialisation à la création (i.e. c'est toujours le
constructeur de l'objet dans la pile qui s'occupe de l'allocation des
ressources, mémoire ou non, et ce sera donc le destructeur de cet objet
qui désallouera les ressources). Après, comme de toute façon faudra
réinitialiser la lib, autant ne pas s'embetter avec (enfin, c'est mon
opinion :P ).

Pour les autres exceptions, ça peut devenir un peu plus difficile
(paradoxalement) car il serait vraiment bien que la levée de ces
exceptions laisse ta lib dans l'état où elle était avant l'appel de la
fonction qui lève l'exception. Dans tous les cas, je te recommande la
lecture des sujets de Guru of the Week concernant les exceptions, tu les
trouveras là :

http://www.gotw.ca/gotw/

Pour les exceptions utilisateurs, c'est le même problème que pour les
précédentes.

Pour la hiérarchie, je ferais trois classes abstraites dérivant
directement de std::exception, une par type d'exception, de façon à
permettre à l'utilisateur de ta lib (i.e. le programmeur) d'intercepter
l'exceptions pertinente où il le veut (par exemple gérer les exceptions
utilisateur de manière centralisée pour avoir un affichage, les
exceptions qui lui sont destinées aux endroits où il pourra y faire
qqch, et les exceptions graves pourront éventuellement donner lieu à un
traitement entrainant la fermeture du programme ...).

Est-ce à l'utilisateur de la bibiliothèque de le faire?
L'utilisateur du programme?

L'utilisateur du programme finale n'a aucune idée de la notion
d'exception et ne devrait jamais l'avoir ! En gros, du moment qu'il a un
bon rapport d'erreur, il se fout de la méthode utilisée (et il a
raison). C'est l'utilisateur de la lib qui sera content d'avoir un
système d'exception bien fait !

Ou bien je laisse les exceptions se déclencher et c'est au programmeur de
se débrouiller comme il veut?

Dans tout les cas, pour ta lib, tu ne spécifies que les exceptions qui
peuvent "sortir" de la lib (i.e. des fonctions de ton utilisateurs
peuvent les voir passer).

Un peu d'aide serait la bienvenue :)

Bah j'espère que ça aide ... en lisant un peu avant, les exceptions
réduisent vraiment de beaucoup les problèmes liés à la gestion des
erreurs. Par contre, ça demande de structure le programme en conséquence
(mais souvent la structuration pour les exceptions à d'autres avantages,
comme ne plus s'occuper *du tout* de la libération des ressources, vu
que c'est fait automatiquement à la destruction des objets ...).

Merci d'avance

Michael

Pierre

Michael wrote:

La question que je me pose en fait est la suivante:
* A qui sont destinées les exceptions? Au concepteur de bibliothèque, à
l'utilisateur de la bibliothèque, ou au client final?

AMA, les exceptions sont utiles pour deux cas (quand tu fais un lib):
1 - pour les erreurs que tu peux récupérer (exceptions "internes", qui
ne sont pas spécifiées car elles ne sortent pas de la lib)
2 - pour les erreurs qui sortiront de la lib car c'est soit la faute de
l'utilisateur, soit une erreur "matérielle" (ou système ou ... un truc
qu'il faut remonter quoi)

Pour les erreurs de programmation, le mieux c'est les assert. Après, tu
peux fournir une version de debug de ta lib si un utilisateur à un doute
... avec la version de debug il pourra te dire si un assert foire !

Ouala mon avis,

Pierre

Par exemple, voici une fonction tirée de la bibliothèque (c'est une
fonction utilisée à l'intérieur de la bibilothèque, qui n'est pas
accessible à l'utilisateur)

//-------------------------------------------------------------------------
void OutputFileDVType2::ConnectToVideoDevice(CComPtr<IBaseFilter> &
pDevice)
{
assert(CheckInputDeviceIsDVCam() == true);

/* Check if the device is the smart tee filter or the real capture device
The process is different in case of the smart tee filter, because we must
use
Dshow::Func::GetPinCategory with NULL parameters on its pin, because the
output pins of the Smart Tee
don't support IEnumMediaTypes and IKsPropertySet. */

CComPtr<IPin> pPinDeviceOutput;

GUID deviceCateg;
if (FAILED(pDevice->GetClassID(&deviceCateg)))
{
//Exception
}

if (deviceCateg == CLSID_SmartTee)
DShow::Func::GetPin(pDevice,NULL,PINDIR_OUTPUT,NULL,pPinDeviceOutput);
else
DShow::Func::GetPin(pDevice,&MEDIATYPE_Interleaved,PINDIR_OUTPUT,
&PIN_CATEGORY_CAPTURE,pPinDeviceOutput);

if (pPinDeviceOutput == NULL)
{
//Exception
}

if (FAILED(Func::ConnectFilters(pGraph,pPinDeviceOutput,pDVSplit)))
{
//Exception
}

//Connect the DV Splitter to the AVI Mux (twice)
if (FAILED(Func::ConnectFilters(pGraph,pDVSplit,pFilter)))
{
//Exception
}

if (FAILED(Func::ConnectFilters(pGraph,pDVSplit,pFilter)))
{
//Exception
}
}

Je me rends compte en fait que les exceptions que je pourrais lancer ici
n'intéressent qu'une seule personne : Moi !! En effet elles me
permettraient de savoir où se trouve une erreur dans le code (Par exemple
quels sont les filtres que je tente de mettre en relation alors qu'ils ne
le devraient pas...)

Mais je me dis que ce pourrait être intéressant de les laisser, ce qui
permettrait à l'utilisateur de la bibliothèque ou à l'utilisateur final de
faire remonter des "codes d'erreur" lancés par les exceptions...




Pour moi écrire la bibliothèque et vérifier que ce que je fais est bon,
est-ce que des simples assert sont suffisants? Auquel cas le code précédent
deviendrait

//-------------------------------------------------------------------------
void OutputFileDVType2::ConnectToVideoDevice(CComPtr<IBaseFilter> &
pDevice)
{
assert(CheckInputDeviceIsDVCam() == true);

/* Check if the device is the smart tee filter or the real capture device
The process is different in case of the smart tee filter, because we must
use
Dshow::Func::GetPinCategory with NULL parameters on its pin, because the
output pins of the Smart Tee
don't support IEnumMediaTypes and IKsPropertySet. */

CComPtr<IPin> pPinDeviceOutput;

GUID deviceCateg;
assert(pDevice->GetClassID(&deviceCateg));

if (deviceCateg == CLSID_SmartTee)
DShow::Func::GetPin(pDevice,NULL,PINDIR_OUTPUT,NULL,pPinDeviceOutput);
else
DShow::Func::GetPin(pDevice,&MEDIATYPE_Interleaved,PINDIR_OUTPUT,
&PIN_CATEGORY_CAPTURE,pPinDeviceOutput);

assert(pPinDeviceOutput != NULL);

assert(Func::ConnectFilters(pGraph,pPinDeviceOutput,pDVSplit));

//Connect the DV Splitter to the AVI Mux (twice)
assert(Func::ConnectFilters(pGraph,pDVSplit,pFilter));

assert(Func::ConnectFilters(pGraph,pDVSplit,pFilter));
}


Et ne lancer des exceptions que lors des fonctions utilisées par
l'utilisateur de la bibliothèque?

Pierre Barbier de Reuille <p.barbierdereuille@free.fr> wrote in news:44e2590c
$0$18265$636a55ce@news.free.fr:

Pour la hi‚rarchie, je ferais trois classes abstraites d‚rivant
directement de std::exception, une par type d'exception, de fa‡on …
permettre … l'utilisateur de ta lib (i.e. le programmeur) d'intercepter
l'exceptions pertinente o— il le veut (par exemple g‚rer les exceptions
utilisateur de maniŠre centralis‚e pour avoir un affichage, les
exceptions qui lui sont destin‚es aux endroits o— il pourra y faire
qqch, et les exceptions graves pourront ‚ventuellement donner lieu … un
traitement entrainant la fermeture du programme ...).

Donc le mieux c'est que tout type d'erreur passe par une exception, puisque
par exemple si dans la lib il est impossible de créer un objet qui doit être
utilisé, il est inutile d'aller plus loin. Et autant avertir tout le monde de
ce qui a foiré.

Quant aux assert, je les utiliserai pour vérifier que les paramètres entrés
par l'utilisateur de la lib sont corrects...

Michael wrote:

Pierre Barbier de Reuille <p.barbierdereuille@free.fr> wrote in news:44e2590c
$0$18265$636a55ce@news.free.fr:

Pour la hi‚rarchie, je ferais trois classes abstraites d‚rivant
directement de std::exception, une par type d'exception, de fa‡on …
permettre … l'utilisateur de ta lib (i.e. le programmeur) d'intercepter
l'exceptions pertinente o— il le veut (par exemple g‚rer les exceptions
utilisateur de maniŠre centralis‚e pour avoir un affichage, les
exceptions qui lui sont destin‚es aux endroits o— il pourra y faire
qqch, et les exceptions graves pourront ‚ventuellement donner lieu … un
traitement entrainant la fermeture du programme ...).

Donc le mieux c'est que tout type d'erreur passe par une exception, puisque
par exemple si dans la lib il est impossible de créer un objet qui doit être
utilisé, il est inutile d'aller plus loin. Et autant avertir tout le monde de
ce qui a foiré.

Quant aux assert, je les utiliserai pour vérifier que les paramètres entrés
par l'utilisateur de la lib sont corrects...

Voilà, pour moi la distinction est:

- Exception : erreur d'utilisation ou matérielle
- Assert : pour vérifier que *je* ne me suis pas trompé quelque part,
de toute façon ce sera supprimé dans la version finale (sans avoir rien
à faire, l'entête <cassert> définit la macro assert comme une fonction
vide si la compilation n'est pas en debug ...)

Pierre

Voilà, pour moi la distinction est:

- Exception : erreur d'utilisation ou matérielle
- Assert : pour vérifier que *je* ne me suis pas trompé quelque part,
de toute façon ce sera supprimé dans la version finale (sans avoir rien
à faire, l'entête <cassert> définit la macro assert comme une fonction
vide si la compilation n'est pas en debug ...)

Concernant la définition des exceptions, est-ce que ceci est utilisé (il y
a des erreurs, mais l'idée est là)(et c'est prévu pour Borland C++ Builder
6)

class DSException : public Exception
{
private:
HRESULT hr;
public:
DSException(HRESULT hr_)
: hr(hr_),Exception("")
{
Message = "DirectShow Errorrn";
Message += "Error Code : " + hr + "rn";
}
};

//------------------------------------------------------------------------
class CoCreateException : public DSException
{
private:
LPOLESTR classString;
public:
CoCreateException(HRESULT hr, const GUID & clsid)
: DSException(hr),classString(NULL)
{
StringFromCLSID(clsid,&classString);
Message += "CoCreateInstanceError with : " + classString;
}
};

De telle sorte que lorsqu'une exception est lancée, le message affiché soit
clair pour tout le monde.

Michael wrote:

Voilà, pour moi la distinction est:

- Exception : erreur d'utilisation ou matérielle
- Assert : pour vérifier que *je* ne me suis pas trompé quelque part,
de toute façon ce sera supprimé dans la version finale (sans avoir rien
à faire, l'entête <cassert> définit la macro assert comme une fonction
vide si la compilation n'est pas en debug ...)

Concernant la définition des exceptions, est-ce que ceci est utilisé (il y
a des erreurs, mais l'idée est là)(et c'est prévu pour Borland C++ Builder
6)

class DSException : public Exception
{
private:
HRESULT hr;
public:
DSException(HRESULT hr_)
: hr(hr_),Exception("")

Non, initialise toujours la classe de base *avant* les variables locales:

DSException(HRESULT hr_)
: Exception("")
, hr(hr_)

{
Message = "DirectShow Errorrn";
Message += "Error Code : " + hr + "rn";
}
};

//------------------------------------------------------------------------
class CoCreateException : public DSException
{
private:
LPOLESTR classString;
public:
CoCreateException(HRESULT hr, const GUID & clsid)
: DSException(hr),classString(NULL)
{
StringFromCLSID(clsid,&classString);
Message += "CoCreateInstanceError with : " + classString;
}
};

De telle sorte que lorsqu'une exception est lancée, le message affiché soit
clair pour tout le monde.

Mmhh ... bon, je dois dire que je ne connais pas du tout les types
bizarres que tu utilises. Mais si Exception est la classe de base pour
Borland .. bah c'est celle qui faut utiliser. Sinon je comprends pas
pourquoi classString est une variable member de CoCreateException et pas
une variable locale : tu ne l'utilises pas hors du constructeur !!

Sinon ça se fait tout à fait d'avoir un message lisible dans
l'exception. Ça se fait aussi de faire des accesseurs pour que
l'utilisateur de la lib ait un accès facile à l'erreur. Dans ton cas, je
rajouterais, dans DSException, une méthode error_number() qui renvoie
hr. Juste au cas où pour certains erreurs, l'utilisateur de la lib
puisse réinitialiser qqch et relancer le processus ...

Pierre

On Wed, 16 Aug 2006 11:48:55 +0100, Pierre Barbier de Reuille
<p.barbierdereuille@free.fr>:

Non, initialise toujours la classe de base *avant*

De toutes façons, quelle que soit la tronche de la liste
d'initialisation, les classes de base sont initialisées d'abord, puis
vient le tour des variables membres, dans l'ordre de déclaration dans
la classe.

les variables locales:

Attention, les variables locales ne sont pas ce que tu sembles croire.
Il s'agit des paramètres de la fonction (ici, "hr_"), ainsi que des
variables déclarées dans le corps de la fonction.

On Wed, 16 Aug 2006 12:59:08 +0200, Fabien LE LEZ
<gramster@gramster.com>:

De toutes façons, quelle que soit la tronche de la liste
d'initialisation, les classes de base sont initialisées d'abord, puis
vient le tour des variables membres, dans l'ordre de déclaration dans
la classe.

Mais bien sûr, respecter cet ordre dans la liste d'initialisation,
même si ça ne change rien au fonctionnement du programme, améliore sa
lisibilité.

Fabien LE LEZ wrote:

On Wed, 16 Aug 2006 11:48:55 +0100, Pierre Barbier de Reuille
<p.barbierdereuille@free.fr>:

Non, initialise toujours la classe de base *avant*

De toutes façons, quelle que soit la tronche de la liste
d'initialisation, les classes de base sont initialisées d'abord, puis
vient le tour des variables membres, dans l'ordre de déclaration dans
la classe.

les variables locales:

Attention, les variables locales ne sont pas ce que tu sembles croire.
Il s'agit des paramètres de la fonction (ici, "hr_"), ainsi que des
variables déclarées dans le corps de la fonction.

En effet, je voulais dire variable membre ...
Pour l'ordre d'initialisation, je sais que g++ génère un warning quand
l'ordre ne correspond pas. Le piège est d'utiliser une variable qui
semble initialisée (car plus haut dans la liste) pour en initialiser une
autre alors qu'en pratique elle ne sera pas initialisée au moment de
l'utilisation (bon, je sais pas si je suis clair ...). Alors un exemple
d'erreur :

struct Toto
{
int a,b,c;
Toto( int i )
: c(i)
, a(c+1)
, b(a+1)
{ }
};


Dans ce cas, les valeurs de a et b sont imprévisibles ...

Pierre