Table des Matières
Publicité
6.4. Gestion des erreurs
Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne
pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un
utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en
pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de
comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour
interpréter les erreurs signalées par la librairie.
La manière la plus simple de contourner le problème est celle que nous avons employé pour
les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est
en ligne avec la fonction
fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait,
mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas
totalement exclure une erreur se produisant après le
le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de
gestion des erreurs décrites ci-dessous.
La méthode recommandée par la plupart des langages de programmation pour la gestion des
erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la
librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la
librairie va lancer une exception. Dans ce cas, de trois choses l'une:
• Si votre code attrape l'exception au vol et la gère, et tout se passe bien.
• Si votre programme tourne dans le debugger, vous pourrez relativement facilement
déterminer où le problème s'est produit, et voir le message explicatif lié à l'exception.
• Sinon... l'exception va crasher votre programme, boum!
Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une
autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans
devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction
yDisableExceptions ()
chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui
peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en
cas d'erreur pour chaque fonction est systématiquement documenté dans la
librairie. Il suit toujours la même logique: une méthode
Y_STATE_INVALID
Y_CURRENTVALUE_INVALID
attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au
pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur
retournée. Dans le cas de fonctions qui ne retournent a priori pas d'information, la valeur de
retour sera
YAPI_SUCCESS
Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un
message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à
l'aide des méthodes
errType ()
auraient été associées à l'exception si elles avaient été actives.
www.yoctopuce.com
et on suppose ensuite qu'il va y rester pendant la
isOnline ()
pour commuter la librairie dans un mode où les exceptions de
,
une
méthode
get_currentValue
, etc. Dans tous les cas, la valeur retournée sera du type
si tout va bien, et un code d'erreur différent en cas d'échec.
et
errMessage ()
, qui pourrait faire planter
isOnline()
retournera une valeur
get_state()
retournera
. Ce sont les même informations qui
référence de la
une
valeur
26
Publicité
Table des Matières
