• Aucun résultat trouvé

Les exceptions sont levées à l’aide de l’instructionthrow, qui prend une instance d’exception en paramètre. Une méthode qui est susceptible de lever une exception doit être signalée à l’interpréteur ou au compilateur en ajoutant la clausethrowssuivi du type de l’exception lors de la déclaration de la méthode.

Un exemple est donné dans la suite :

// ======================================================== //

// Fichier: MonException.java //

// Auteur: osd (Olivier Sigaud) //

// ======================================================== //

public class MonException extends Exception { /** * constructeur */ public MonException() {

// appel du constructeur de la classe Exception super("Ceci est une exception perso");

}

// fin de MonException }

// ======================================================= //

// Fichier: MaClasse.java //

// Auteur: osd (Olivier Sigaud) //

// ======================================================= //

/**

* Classe quelconque

22Le nomThrowablelaisse à penser que cette classe a d’abord été conçue comme une interface, puis le

*/

public class MaClasse { /** * constructeur */ public MaClasse() { } /**

* méthode qui renvoie une exception */

public void maMethodeGenerantException() throws MonException {

// appel du constructeur de la classe MonException if (erreur) throw new MonException("Message d’erreur"); }

// fin de MaClasse }

Lorsqu’une méthode est susceptible de lever une exception, toutes les méthodes qui l’appellent doivent obligatoirement capturer cette exception.

Cette capture s’effectue à l’aide de la séquence d’instructions suivante :

try { maMethodeGenerantException(); } catch(MonException e) {

// traitement du cas où l’exception est levée }

Un traitement typique du cas où l’exception est levée est le suivant :

... catch(MonException e) { e.printStackTrace(); System.exit(-1); }

La première instruction, e.printStackTrace() ;, affiche l’arbre d’appel de la méthode qui a engendré l’exception. On sait ainsi immédiatement dans quel contexte l’erreur s’est produite.

La seconde instruction,System.exit(-1) ;, arrête le programme avec une va- leur de retour signalant une erreur.

7

Les interfaces graphiques

La facilité de mise au point d’interfaces graphiques en JAVAest l’un des éléments qui contribuent le plus massivement au succès de ce langage de programmation.

Les premières versions de JAVAétaient livrées avec un package nommé AWT23

chargé de faire le lien entre le langage et les serveurs graphiques des différents systèmes d’exploitation dans lesquels la machine virtuelle de JAVAest implantée.

Cette situation présentait un inconvénient majeur. Les concepteurs de machines virtuelles JAVA étaient contraints de fournir un package AWTdifférent pour chaque système d’exploitation. Outre le sur-coût que cela implique, cela entraînait des dispa- rités de fonctionnement d’un système d’exploitation à l’autre, ce qui est contraire à la volonté de portabilité maximale affichée par les concepteurs de JAVA.

C’est pour mettre fin à cette situation que le package SWINGa été mis au point à partir de la version 1.1 duJDK. De l’extérieur, le programmeur habitué à l’AWT a l’impression de retrouver ce dont il a l’habitude quand il passe à SWING. La plupart des classes de l’AWTont leur équivalent dans SWING, à une légère altération du nom près, pour permettre la cohabitation entre les deux familles de classes :Framedevient JFrame,PaneldevientJPanel, etc.

Mais les choses ont profondément changé quand on y regarde de plus près. Tout d’abord, SWING ne repose plus sur les serveurs graphiques des différents systèmes d’exploitation. Toutes les fonctionnalités de haut niveau offertes par ces serveurs – gestion de fenêtres, d’événements, de composants graphiques divers – ont été recodées directement au cœur du package SWING. Seul subsiste l’appel qui permet d’allumer un pixel donné dans une couleur donnée, ce qui garantit une portabilité totale d’un système d’exploitation à l’autre.

Ensuite, le modèle de programmation auquel incite l’utilisation de SWINGest plus conforme à ce qui est largement préconisé en matière de méthodologie de développe- ment d’interfaces graphiques. Il est en effet naturel quand on utilise SWINGde déve- lopper une interface graphique conformément au modèle MVC, qui s’impose comme un standard de modélisation d’interfaces.

7.1

Le modèle MVC

Le modèle MVC est un « design pattern » issu de Smalltalk-80. MVC signifie Model View Controller. Il s’agit d’une façon d’organiser les différents composants d’un logiciel de façon à faciliter la réutilisation et éviter des problèmes de conception et d’implémentation. Ce modèle est très générique et ne s’applique pas qu’aux interfaces

graphiques, même si c’est pour la conception d’interfaces graphiques qu’il est le plus utile.

Comme son nom l’indique, ce modèle contient trois composants :

1. Model : la partie « modèle » correspond au cœur de l’application. Elle contient les données que le programme manipule et gère les changements d’états induits par les opérations sur ces données.

2. View : la partie « vue » correspond à l’interface en sortie présentée à l’utilisateur pour lui donner connaissance de l’état de la partie « modèle ».

3. Controller : la partie « contrôleur » correspond à l’interface en entrée présentée à l’utilisateur pour interagir avec la partie « modèle ».

À une même partie « modèle » peuvent être associées plusieurs vues, destinées à plu- sieurs utilisateurs ou à un seul. À chaque fois que l’état de la partie « modèle » change, il faut informer du changement chacune des vues concernées par la modification, afin que celles-ci mettent à jour l’information présentée aux utilisateurs. De même, chaque action de l’utilisateur doit être transmise par un contrôleur à la partie « modèle » pour donner lieu à une action sur les données.

La façon la plus propre de gérer ces interactions entre vues, modèle et contrôleur est de notifier tout changement qui concerne l’un ou l’autre des éléments sous la forme d’un événement. Les différents composants s’abonnent à des sources d’événements et se voient notifier ceux-ci lorsqu’ils se produisent.

Nous exposons la façon de gérer les événements en JAVAdans la section suivante.

Documents relatifs