À l'aide de l'essayer..sauf pour gérer les erreurs

A l'aide de l'essayer..sauf pour gerer les erreurs

A l'aide de l'essayer..sauf pour gerer les erreurs : Plusieurs milliers de conseils pour vous faciliter la vie.

Apprendre sur les exceptions et comment mieux ecrire le code de gestion d'erreur. Apprendre Castalia peut nous aider a ecrire plus robuste et a tolerance de pannes code.

(publie a l'Origine sur delphi-expert.com sur Mars 23, 2004)

Comme promis, c'est aujourd'hui la deuxieme partie de notre discussion de Delphi essayer des constructions. La semaine derniere, nous avons cherche a try..finally, a appris ce qu'il veut, quand les utiliser et comment Castalia pouvez nous aider a l'utiliser de maniere plus efficace. Cette semaine, nous nous pencherons sur l'autre moitie de la essayer de la famille, essayer..sauf et d'apprendre comment Castalia pouvons faire de notre essayer..sauf utilisation plus efficace. Il nous fera egalement plaisir de java.

Essayer..sauf est une construction pour la manipulation des situations 'exceptionnelles' dans un programme. Un programme a un flux typique, qui est un ensemble d'instructions qui se deroulent dans l'ordre. Parfois, cette commande fait l'objet de branches, mais il y a toujours une logique de flux, et les decisions de la direction generale que les flux sont bases sur un certain etat du programme, comme si X est inferieur a 5.

Parfois, cependant, l'etat ne peut etre rendu incorrect. Prenons un exemple, que nous pourrions voir dans le monde reel:

AssignFile(F, 'SomeFile.Txt')
ResetFile(F)
S := ReadLn(F)
CloseFile(F)

Ce code simple ouvrir un fichier, lire une ligne, et la refermer. C'est le deroulement normal du programme. Cependant, un certain nombre d'hypotheses sont faites a propos de ce flux. Tout d'abord, nous supposons que le fichier existe. Nous supposons que nous pouvons l'ouvrir pour le lire. Nous supposons qu'il existe une ligne a lire. Etc...

Si l'un de ces hypotheses s'avere etre fausse, alors nous avons une situation exceptionnelle! Le flux du programme va etre gache par le fait que certains etats n'est pas l'etat que nous avons attendu.

Il y a plusieurs façons de le gerer ces situations exceptionnelles. On peut les ignorer, et si l'un d'eux se produit, le programme va planter ou de faire autre chose tout aussi erratique. Nous avons pu verifier ces exceptions, l'ajout de code comme ceci:

si non FileExists('SomeFile.txt'),
begin
WriteLn('le Fichier n'existe pas')
Sortie
fin

C'est mieux. Pour une chose, vous avez dit a l'utilisateur pourquoi le programme ne fonctionnera pas. Pour des programmes simples, cela fonctionne bien, mais comme le programme devient de plus en plus complexe, l'etat du programme croît de maniere exponentielle complexe, et bientot vous serez en mesure de verifier toutes les hypotheses. Verifier vos hypotheses est une bonne chose. Nous y reviendrons plus tard.

Nous pouvons aussi checkafter chaque operation afin de s'assurer que ce qui nous attendait. C'est le traditionnel C de l'approche et de l'approche de l'API Windows (et la plupart des autres Api du systeme d'exploitation, avec BeOS comme une exception notable). Dans ce modele, chaque fonction renvoie un code d'erreur. Il est de votre responsabilite de verifier le code d'erreur et de voir si elle est 'OK' ou quelque chose comme FILE_NOT_FOUND. Alors, encore une fois, vous vous en informer l'utilisateur et de sortie.

C'est, en fin de compte, une variation sur la meme approche, mais cette fois nous verifions les hypotheses apres nous faisons quelque chose, plutot qu'avant. L'avantage est que chaque fonction peut verifier ses hypotheses, et dans le cas de l'API Windows, toutes les valeurs de retour possibles sont assez bien documentes, donc avec disciplinee de l'ecriture, il est effectivement possible de gerer toutes les conditions, en supposant que celui qui a ecrit l'API a pris toutes ses hypotheses en consideration. Le Code ecrit avec cette approche devrait ressembler a quelque chose comme ça (Non, ce n'est pas valable pascal, mes excuses pour les puristes):

ErrCode := AssignFile(F, 'SomeFile.Txt')
si ErrCode = FILE_NOT_FOUND puis
begin
WriteLn ('Fichier Non Trouve')
Sortie
fin
ErrCode := ResetFile(F)
si ErrCode = FILE_NO_ACCESS puis
begin
WriteLn('Vous n'avez pas acces a le faire.')
Sortie
else
si ErrCode = FILE_ALREADY_OPEN puis
begin
WriteLn('Quelqu'un d'autre est de la lecture du fichier')
Sortie
fin
ErrCode := ReadLn(F, S) //Nous allons supposer qu'il s'agit de lire a partir de F dans S
si ErrCode = NOT_ENOUGH_TEXT puis
begin
WriteLn ('Pas Assez de Texte')
Sortie
fin
CloseFile(F)

Vous avez l'idee. Il pourrait etre bien pire, mais notre programme a obtenu vraiment complexe vraiment rapidement, et tous les a accueillir des choses qui ne sont normalement pas se produire.

Donc, quelqu'un au cours des deux dernieres decennies a eu une nouvelle idee. Pourquoi ne pas creer une structure de controle specifiquement pour les situations exceptionnelles? Cette nouvelle pourrait structure de controle qui nous permettrait de definir ce qui doit arriver normalement, puis definir ce qui doit arriver si quelque chose va mal. Ceci est connu comme 'la gestion des exceptions.'

L'idee de base derriere une exception, c'est que nous supposons que le flux de controle est va prendre place. Si ça ne marche pas, nous avons immediatement arreter l'execution la ou nous sommes et quitter la fonction. Nous avons ensuite quitter la fonction qui a appele cette fonction, et ainsi de suite, jusqu'a ce que, nous arrivons a un gestionnaire d'exception, qui est un bloc de code qui est execute uniquement lors d'un etat d'exception ou d'un evenement a lieu. Si l'ecoulement normal de l'execution est suivie, les gestionnaires d'exception sont ignores.

En Delphi, le flux normal de l'execution est dans un bloc try, et le gestionnaire d'exception est une exception a bloc. Voici un exemple simple:

AssignFIle(F, 'SomeFile.txt')
ResetFile(F)
S := Readln(F)
CloseFile(F)
sauf
WriteLn('Une erreur est survenue')
fin

C'est plus propre, et il nous permet de voir clairement ce code, nous nous attendons a etre execute normalement, et ce code doit etre execute quand quelque chose de bizarre se passe (pas comme le dernier exemple... frisson).

bien sûr, il serait agreable d'etre en mesure de dire exactement quelle erreur s'est produite. La gestion des exceptions en fait une brise trop. Depuis la gestion des exceptions developpe main dans la main avec la programmation orientee objet, les choses appelee exception des objets ont ete conçus. L'objet de l'exception est automatiquement cree lorsqu'une exception est levee. Si nous voulons utiliser l'objet de l'exception, nous prolongeons l'essayer..sauf la syntaxe ressemble a ceci:

AssignFile(F, 'SomeFile.txt')
ResetFile(F)
S := Readln(F)
CloseFile(F)
sauf
E: Exception ne
WriteLn(E. Message)
fin

voyez-Vous, chaque exception a un Message de la propriete qui donne quelques informations utiles a propos de l'exception. Il peut contenir la chaîne 'Fichier introuvable' ou 'Fichier en cours d'utilisation', ou quelque chose d'autre que nous voudrions dire a l'utilisateur.

Il y a differents types d'exceptions, et on peut en profiter aussi. Peut-etre que nous voulons faire quelque chose de special lorsqu'une exception se produit. Peut-etre que nous voulons bip si le fichier n'est pas trouve:

AssignFile(F, 'SomeFile.txt')
ResetFile(F)
S := REadln(F)
CloseFIle(F)
sauf
E: fichier introuvable faire
Bip
E: Exception ne
WriteLn(E. Message)
fin

Notez que, lorsque nous nous occupons de plusieurs exceptions, la plupart exception specifique doit passer en premier. C'est parce que les exceptions sont polymorphes, Exception est TOUS d'exception, et EFileNotFound est une Exception, si l'Exception est traitee en premier, EFileNotFound ne seront jamais traitees.

Un probleme avec ce mecanisme, c'est que nous ne sommes pas encore sûr de ce que d'exceptions, en particulier de la fonction ou de la procedure pourrait soulever. Certains langages ou d'outils de developpement de disposer d'un mecanisme pour vous aider a savoir ce qui pourrait etre soulevee. On C# IDE, par exemple, vous donnera une petite fenetre de conseil pour vous dire quelles sont les exceptions vous devez gerer a chaque fois que vous utilisez une fonction. Java est notoire (et deteste par beaucoup) pour le fait qu'il applique la gestion des exceptions avec les terroristes de zele. Votre code ne sera meme pas compiler si vous n'avez pas gerer les exceptions qu'elle veut que vous, meme si vous SAVEZ que ces exceptions ne sont pas en train de se produire, soit parce que vous avez le controle sur l'environnement en cours d'execution, ou votre code a deja prechecked la condition et s'est assure que l'exception ne peut pas etre levee. Java impose son style de code a la derniere iota et iota, si vous l'aimez ou pas.

Malheureusement, aucun outil de ce type n'existe pour Delphi. Comme je l'ai ecris cela, je commence a penser qu'il pourrait etre une bonne chose a ajouter a Castalia. Je vais regarder a cela.

Ouf!

C'etait en trois pages et demi de Microsoft Word, afin de comprendre la nature d'une exception. Maintenant pour le fun stuff:

Castalia peut vous aider a ecrire votre code et votre code de gestion des exceptions. Castalia du code de modeles de definir un trye modele qui cree automatiquement un essayer..sauf bloc pour vous et met en place des points d'entree de sorte que vous pouvez creer correctement votre code. Cela vous permettra d'economiser plus de frappes et de plus de temps que vous vous rendez compte!

Castalia du refactoring de fournir un systeme automatise de surround avec... refactoring qui va mettre un try..except bloc autour de votre code. Il suffit de selectionner le flux normal de controle de code, cliquez-droit sur l'editeur (ou appuyez sur les touches Maj Ctrl R), et selectionnez l'element approprie dans le refactoring menu. Le code sera modifie automatiquement.

Cette semaine, nous avons appris que le coup d'essayer..sauf bloc de l'est et d'ou il venait et pourquoi il est le meilleur mecanisme de gestion des erreurs encore). Nous avons aussi appris comment Castalia pouvez faire de votre utilisation de ce puissant structure de controle d'ecrire plus robuste et convivial code.

Pour plus d'informations sur Castalia de modeles de code, cliquez ici.

Pour plus d'informations sur Castalia automatise de refactorings, cliquez ici

Pour acheter Castalia des maintenant, parce que cet article etait la meilleure chose que vous avez jamais lu, cliquez ici, puis cliquez sur ici pour lire un nettement mieux.