Gestion des erreurs

« Gérer » une erreur signifie que vous intégrez des fonctions logiques à l’application pour réagir à une erreur ou la corriger. Les erreurs sont générées lors de la compilation d’une application ou lors de l’exécution d’une application compilée. Lorsque l’application gère les erreurs, il se produit une réaction à l’erreur. Il arrive en revanche qu’une erreur soit ignorée (auquel cas le processus à l’origine de l’erreur échoue silencieusement). La gestion des erreurs, lorsqu’elle est utilisée correctement, protège votre application et ses utilisateurs contre un comportement inattendu.

Cependant, la gestion des erreurs est une catégorie large qui englobe la réponse à de nombreux types d’erreurs générées lors de la phase de compilation ou lors de l’exécution d’une application. Nous allons passer en revue la gestion des erreurs d’exécution (renvoyées lors de l’exécution d’une application), les différents types d’erreurs générés et les avantages du système de gestion des erreurs d’ActionScript 3.0.

Principes de base de la gestion des erreurs

Une erreur d’exécution est une erreur qui se produit dans votre code ActionScript et qui empêche le contenu ActionScript de s’exécuter comme prévu. Pour assurer l’exécution correcte du code ActionScript du point de vue de l’utilisateur, écrivez le code dans l’application qui gère l’erreur (la corrige, la contourne ou informe au moins l’utilisateur qu’elle a eu lieu). Ce processus est appelé gestion des erreurs.

La gestion des erreurs est une catégorie large qui englobe la réponse à de nombreux types d’erreurs générées lors de la phase de compilation ou lors de l’exécution d’une application. Les erreurs qui se produisent lors de la compilation sont souvent plus faciles à identifier. Corrigez-les pour terminer la création d’un fichier SWF.

Les erreurs d’exécution peuvent être difficiles à détecter car elles se produisent lorsque le code erroné est exécuté. Si un segment de votre programme contient plusieurs branches de code, telle une instruction if..then..else, testez toutes les conditions possibles, avec toutes les valeurs en entrée susceptibles d’être utilisées par un utilisateur réel, pour confirmer que le code ne contient pas d’erreur.

Les erreurs d’exécution peuvent être divisées en deux catégories : les erreurs de programme sont des erreurs dans votre code ActionScript (spécification du type de données incorrect pour un paramètre de méthode, par exemple) ; les

erreurs logiques sont des erreurs dans la logique (le contrôle des données et la manipulation des valeurs) de votre

programme (utilisation de la formule incorrecte pour calculer les taux d’intérêt dans une application bancaire, par exemple). Encore une fois, ces deux types d’erreurs peuvent souvent être détectés et corrigés à l’avance en testant attentivement votre application.

Il serait idéal d’identifier et de supprimer toutes les erreurs de votre application avant de la mettre à la disposition des utilisateurs finaux. Cependant, toutes les erreurs ne peuvent pas être prévues ni évitées. Supposons, par exemple, que l’application ActionScript charge des informations depuis un site Web particulier sur lequel vous n’avez aucun contrôle. Si ce site Web n’est pas disponible, la partie de l’application qui dépend de ces données externes ne se comporte pas correctement. L’aspect primordial de la gestion des erreurs consiste à anticiper ces cas de figure et à les traiter judicieusement. Il est préférable que l’exécution de l’application ne soit pas interrompue ou, tout du moins, qu’un message indique à l’utilisateur pourquoi elle ne fonctionne pas.

Les erreurs d’exécution sont représentées de deux façons dans ActionScript :

• Classes d’erreur : de nombreuses erreurs sont associées à une classe Error. Lorsqu’une erreur se produit, le moteur d’exécution Flash (Flash Player ou Adobe AIR, par exemple) crée une occurrence de la classe Error spécifique associée à cette erreur. Votre code peut utiliser les informations contenues dans cet objet erreur pour donner une réponse appropriée à l’erreur.

• Evénements d’erreur : il arrive qu’une erreur se produise lorsque le moteur d’exécution Flash déclencherait normalement un événement. Si tel est le cas, un événement d’erreur est alors déclenché. Chaque événement d’erreur étant associé à une classe, le moteur d’exécution de Flash transmet une occurrence de cette classe aux méthodes enregistrées auprès de l’événement d’erreur.

Pour déterminer si une méthode donnée peut déclencher une erreur ou un événement d’erreur, voir la rubrique correspondante dans le manuel Guide de référence ActionScript 3.0 pour la plate-forme Adobe Flash.

Concepts importants et terminologie

La liste de référence suivante contient des termes importants relatifs à la programmation de routines de gestion des erreurs :

Asynchrone Commande de programme telle qu’un appel de méthode qui ne fournit pas un résultat immédiat, mais qui produit un résultat (ou une erreur) sous la forme d’un événement.

Capture Lorsqu’une exception (une erreur d’exécution) se produit et que votre code la découvre, ce dernier la capture. Lorsqu’une exception est capturée, le moteur d’exécution Flash cesse d’indiquer à un autre code ActionScript que l’exception s’est produite.

Version de débogage Version spéciale du moteur d’exécution Flash, telle que la version de débogage de Flash Player ou l’application de débogage du lanceur AIR (ADL), qui contient le code requis pour avertir les utilisateurs de la présence d’erreurs d’exécution. Dans la version standard de Flash Player ou Adobe AIR (celle que possèdent la plupart des utilisateurs), les erreurs qui ne sont pas gérées par votre code ActionScript sont ignorées. Dans les versions de débogage (intégrées à Adobe Flash CS4 Professional et Adobe Flash Builder), un message d’avertissement apparaît lorsqu’une erreur non gérée se produit.

Exception Erreur qui se produit lorsqu’une application est en cours d’exécution et que le moteur d’exécution Flash ne peut pas la résoudre seul.

Renvoi Lorsque votre code capture une exception, le moteur d’exécution Flash cesse de signaler l’exception à d’autres objets. S’il est important pour d’autres objets que l’exception leur soit signalée, le code doit renvoyer l’exception pour recommencer le processus de notification.

Synchrone Commande de programme (un appel de méthode, par exemple) qui fournit un résultat immédiat (ou qui renvoie immédiatement une erreur), ce qui signifie que la réponse peut être utilisée dans le même bloc de code. Envoi Le fait de signaler au moteur d’exécution Flash (et par conséquent, à d’autres objets et au code ActionScript) qu’une erreur s’est produite s’appelle envoyer une erreur.

Types d’erreurs

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

Lorsque vous développez et exécutez des applications, vous rencontrez différents types d’erreurs et de termes. La liste suivante présente les principaux termes et types d’erreurs :

• Erreurs de compilation : générées par le compilateur ActionScript lors de la compilation du code. Les erreurs de

compilation ont lieu lorsque des problèmes de syntaxe dans votre code empêchent de créer votre application.

• Erreurs d’exécution : générées lorsque vous exécutez votre application après l’avoir compilée. Les erreurs

d’exécution représentent des erreurs qui se produisent lors de la lecture d’un fichier SWF dans un moteur d’exécution Flash tel qu’Adobe Flash Player ou Adobe AIR. Dans la plupart des cas, il est possible de gérer les erreurs d’exécution au moment où elles se produisent, de les signaler à l’utilisateur et de prendre les mesures requises pour poursuivre l’exécution de l’application. S’il s’agit d’une erreur grave (impossibilité de se connecter à un site Web distant ou de charger des données), vous pouvez utiliser la gestion des erreurs pour mettre fin à l’application en douceur.

• Erreurs synchrones : erreurs d’exécution générées lorsqu’une fonction est appelée. Par exemple, lorsque vous tentez

d’utiliser une méthode spécifique et que l’argument que vous lui transmettez n’est pas valide, le moteur d’exécution de Flash renvoie une exception. La plupart des erreurs se produisent en mode synchrone (au moment de l’exécution d’une instruction) et le flux de contrôle passe immédiatement à l’instruction catch la plus appropriée.

Par exemple, l’extrait de code suivant renvoie une erreur d’exécution, car la méthode browse() n’est pas appelée avant que le programme ne tente de charger un fichier :

var fileRef:FileReference = new FileReference(); try { fileRef.upload(new URLRequest("http://www.yourdomain.com/fileupload.cfm")); } catch (error:IllegalOperationError) { trace(error);

// Error #2037: Functions called in incorrect sequence, or earlier // call was unsuccessful.

}

Dans ce cas, une erreur d’exécution est renvoyée de façon synchrone car Flash Player a déterminé que la méthode

browse() n’a pas été appelée avant la tentative de chargement du fichier.

Pour obtenir des informations détaillées relatives à la gestion des erreurs synchrones, voir « Gestion des erreurs synchrones dans une application » à la page 59.

• Les erreursasynchrones sont des erreurs du moteur d’exécution qui se produisent hors du flux normal du programme. Elles génèrent des événements, interceptés par des écouteurs d’événement. Une opération asynchrone est une opération dans laquelle une fonction lance une opération mais n’attend pas qu’elle se termine. Vous pouvez créer un écouteur d’événements d’erreur pour attendre que l’application ou l’utilisateur tente une opération. Si cette dernière échoue, vous interceptez l’erreur avec un écouteur d’événements et répondez à l’événement d’erreur. Ensuite, l’écouteur d’événement appelle une fonction de gestionnaire d’événement pour répondre à l’événement d’erreur avec pertinence. Par exemple, le gestionnaire d’événement peut lancer une boîte de dialogue qui invite l’utilisateur à résoudre l’erreur.

Reprenez l’exemple d’erreur synchrone lors du chargement d’un fichier présenté précédemment. Si vous réussissez à appeler la méthode browse() avant de lancer le chargement d’un fichier, Flash Player distribue plusieurs événements. Par exemple, au démarrage d’un chargement, l’événement open est distribué. A la fin du chargement, l’événement complete est distribué. Etant donné que la gestion d’événements est asynchrone (c’est-à-dire qu’elle n’a pas lieu à des moments prédéfinis, connus et spécifiques), faites appel à la méthode addEventListener() pour détecter ces événements spécifiques, comme l’indique le code suivant :

var fileRef:FileReference = new FileReference(); fileRef.addEventListener(Event.SELECT, selectHandler); fileRef.addEventListener(Event.OPEN, openHandler); fileRef.addEventListener(Event.COMPLETE, completeHandler); fileRef.browse(); function selectHandler(event:Event):void { trace("...select...");

var request:URLRequest = new URLRequest("http://www.yourdomain.com/fileupload.cfm"); request.method = URLRequestMethod.POST; event.target.upload(request); } function openHandler(event:Event):void { trace("...open..."); } function completeHandler(event:Event):void { trace("...complete..."); }

Pour obtenir des informations détaillées sur la gestion des erreurs asynchrones, voir « Réponse à des événements et à l’état d’erreur » à la page 65.

• Exceptions non interceptées : renvoyées sans logique correspondante (telle une instruction catch) pour y répondre. Si votre application renvoie une erreur, et qu’aucune instruction catch ni gestionnaire d’événement approprié n’est trouvé au niveau actuel ou supérieur pour gérer l’erreur, cette dernière est considérée comme une exception non interceptée.

Lorsqu’il se produit une erreur non interceptée, le moteur d’exécution distribue un événement uncaughtError. Cet événement porte également le nom de « gestionnaire d’erreur global ». Il est distribué par l’objet

UncaughtErrorEvents du fichier SWF et est proposé par la propriété LoaderInfo.uncaughtErrorEvents. Si aucun écouteur n’est enregistré pour l’événement uncaughtError, le moteur d’exécution ignore les erreurs non interceptées et tente de poursuivre son exécution, dès lors que l’erreur n’interrompt pas le fichier SWF.

Outre la distribution de l’événement uncaughtError, les versions de débogage du moteur d’exécution de Flash répondent aux erreurs non interceptées en mettant fin au script actif. Elles affichent ensuite les erreurs non interceptées dans le résultat de l’instruction trace ou écrivent le message d’erreur dans un fichier journal. Si l’objet exception est une occurrence de la classe Error ou de l’une de ses sous-classes, les informations de trace de la pile s’affichent également dans le résultat. Pour plus d’informations sur l’utilisation de la version de débogage des moteurs d’exécution Flash, voir « Utilisation des versions de débogage des moteurs d’exécution Flash » à la page 58.

Remarque : lors du traitement d’un événement uncaughtError, si un événement d’erreur est renvoyé par un

gestionnaire uncaughtError, celui-ci est appelé plusieurs fois. Il se produit alors une boucle infinie d’exceptions. Il est donc recommandé d’éviter ce type de scénario.

Gestion des erreurs dans ActionScript 3.0

Etant donné que de nombreuses applications peuvent être exécutées sans créer de logique pour gérer les erreurs, les développeurs sont tentés de retarder la création de la gestion des erreurs dans leurs applications. Néanmoins, sans gestion des erreurs, une application risque de s’interrompre ou de poser des problèmes à l’utilisateur si elle ne fonctionne pas comme prévu. ActionScript 2.0 possède une classe Error qui vous permet de créer une logique dans des fonctions personnalisées afin de renvoyer une exception avec un message spécifique. Etant donné que la gestion des erreurs est cruciale pour rendre une application conviviale, ActionScript 3.0 inclut une architecture étendue pour intercepter les erreurs.

Remarque : bien que le manuel Guide de référence ActionScript 3.0 pour la plate-forme Adobe Flash passe en revue les

exceptions renvoyées par de nombreuses méthodes, il ne contient pas nécessairement toutes les exceptions associées à chaque méthode. une méthode risque de renvoyer une exception due à une erreur de syntaxe ou d’autres problèmes qui ne sont pas signalés explicitement dans la description de la méthode, même si cette dernière répertorie certaines exceptions renvoyées.

Eléments de gestion des erreurs ActionScript 3.0

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

ActionScript 3.0 comprend de nombreux outils permettant de gérer les erreurs, notamment :

• Classes Error : ActionScript 3.0 comprend un large éventail de classes Error destinées à multiplier le nombre de situations susceptibles de produire des objets d’erreur. Chaque classe Error permet aux applications de gérer et de répondre à des conditions d’erreur spécifiques, qu’elles soient liées à des erreurs système (comme une condition MemoryError), à des erreurs de codage (comme une condition ArgumentError), à des erreurs de réseau et de communication (comme une condition URIError), ou d’autres situations. Pour plus d’informations sur chaque classe, voir « Comparaison des classes Error » à la page 68.

• Moins d’échecs silencieux : dans les versions précédentes de Flash Player, les erreurs étaient générées et signalées uniquement si vous utilisiez explicitement l’instruction throw. Les méthodes et propriétés ActionScript natives renvoient des erreurs d’exécution pour le moteur d’exécution de Flash Player 9 et des versions ultérieures de Flash. Ces erreurs permettent de gérer les exceptions de manière plus efficace au moment où elles se produisent, puis de réagir à chaque exception.

• Messages d’erreur clairs affichés lors du débogage : Lorsque vous utilisez la version de débogage d’un moteur d’exécution de Flash, les situations ou le code à l’origine du problème génèrent des messages d’erreur détaillés qui vous aident à identifier les raisons de l’échec d’un bloc de code particulier. Ces messages optimisent la résolution des erreurs. Pour plus d’informations, voir « Utilisation des versions de débogage des moteurs d’exécution Flash » à la page 58.

• Les erreurs précises permettent d’afficher des messages d’erreur clairs pour les utilisateurs. Dans les versions précédentes de Flash Player, la méthode FileReference.upload() renvoyait la valeur booléenne false en cas d’échec de l’appel upload(), indiquant l’une des cinq erreurs possibles. Si une erreur se produit lorsque vous appelez la méthode upload() dans ActionScript 3.0, quatre erreurs spécifiques vous aident à afficher des messages d’erreur plus précis à l’intention des utilisateurs finaux.

• Gestion des erreurs affinée : des erreurs distinctes sont renvoyées pour de nombreuses situations courantes. Par exemple, dans ActionScript 2.0, avant qu’un objet FileReference ne soit renseigné, la propriété name possède la valeur null (par conséquent, avant d’utiliser ou d’afficher la propriété name, vérifiez qu’elle est définie sur une valeur autre que null). Dans ActionScript 3.0, si vous tentez d’accéder à la propriété name avant qu’elle ne soit renseignée, Flash Player ou AIR renvoie une erreur IllegalOperationError qui vous indique que la valeur n’a pas été définie. Vous pouvez utiliser des blocs try..catch..finally pour gérer l’erreur. Pour plus d’informations, voir « Utilisation des instructions try..catch..finally » à la page 59.

• Aucun problème sérieux de performance : l’utilisation de blocs try..catch..finally pour gérer des erreurs ne nécessite pas ou peu de ressources supplémentaires par rapport aux versions précédentes d’ActionScript.

• Une classe ErrorEvent qui vous permet de créer des écouteurs pour des événements d’erreurs asynchrones spécifiques : pour plus d’informations, voir « Réponse à des événements et à l’état d’erreur » à la page 65.

Stratégies de gestion des erreurs

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

Tant que l’application ne rencontre pas de condition problématique, vous pouvez continuer à l’exécuter sans créer de logique de gestion des erreurs dans le code. En revanche, si vous ne gérez pas d’erreurs de façon active et que votre application rencontre un problème, vos utilisateurs ignoreront toujours la raison de son échec.

Vous pouvez aborder la gestion des erreurs de diverses façons dans votre application. La liste suivante résume les trois principales options de gestion des erreurs :

• Utilisez les instructions try..catch..finally. Ces instructions interceptent les erreurs synchrones lorsqu’elles se produisent. Vous pouvez imbriquer vos instructions dans une hiérarchie pour intercepter des exceptions à différents niveaux d’exécution du code. Pour plus d’informations, voir « Utilisation des instructions

try..catch..finally » à la page 59.

• Créez des objets d’erreur personnalisés. Vous pouvez utiliser la classe Error pour créer des objets d’erreur personnalisés afin de suivre des opérations spécifiques dans votre application qui ne sont pas couvertes par des types d’erreur intégrés. Vous pouvez ensuite appliquer des instructions try..catch..finally aux objets d’erreur personnalisés. Pour plus d’informations, voir « Création de classes d’erreur personnalisées » à la page 64.

• Ecrivez des gestionnaires et des écouteurs d’événement pour répondre à des événements d’erreur. Cette stratégie permet de créer des gestionnaires d’erreurs globaux destinés à gérer des événements similaires sans dupliquer un volume élevé de code dans les blocs try..catch..finally. Il est également plus probable que vous interceptiez des erreurs asynchrones à l’aide de cette approche. Pour plus d’informations, voir « Réponse à des événements et à l’état d’erreur » à la page 65.

Utilisation des versions de débogage des moteurs

d’exécution Flash

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

Adobe propose aux développeurs des éditions spéciales des moteurs d’exécution Flash, destinées à les aider à exécuter des opérations de débogage. Vous obtenez une copie de la version de débogage de Flash Player lorsque vous installez Adobe Flash Professional ou Adobe Flash Builder. Vous disposez également d’un utilitaire de débogage des

applications Adobe AIR, appelé ADL, lorsque vous installez l’un de ces outils ou dans le cadre de l’installation du SDK d’Adobe AIR.

Il existe une grande différence dans la façon dont les versions de débogage et les versions de Flash Player et Adobe AIR mises sur le marché signalent les erreurs. Les versions de débogage indiquent le type d’erreur (Error, IOError ou EOFError générique), le numéro de l’erreur et un message d’erreur sous une forme lisible par une personne. Les versions mises sur le marché indiquent uniquement le type d’erreur et son numéro. Considérons par exemple le code qui suit : try { tf.text = myByteArray.readBoolean(); } catch (error:EOFError) { tf.text = error.toString(); }

Si la méthode readBoolean() renvoie une erreur EOFError dans la version de débogage de Flash Player, le message suivant s’affiche dans le champ de texte tf : « EOFError: Erreur #2030: Fin de fichier détectée ».

Dans une version commerciale de Flash Player ou d’Adobe AIR, le même code afficherait le texte suivant : « EOFError: Erreur #2030 ».

Remarque : étant donné que les lecteurs de débogage diffusent l’événement « allComplete », évitez de créer des

événements personnalisés portant le nom « allComplete ». Vous risquez sinon de rencontrer un comportement imprévisible lors du débogage.

Ce type de version ne comprend pas de chaîne de message d’erreur, afin de réduire au minimum la taille et les ressources requises. Vous pouvez consulter le numéro d’erreur dans la documentation (annexes du manuel Guide de