Discussion :

[NeoGeoo]

Bonjour,


j'ai une question peut etre bizarre :


je veux mettre en place une fonction non bloquante. c'est à dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public FTP( ) {

  boolean connecter( );
  void signalerErreurParMail();
  ...
}

je voudrais que lorsque connecter() génère une exception, la fonction FTP() continue à s'exécuter sans tenir compte du résultat de connecter(). L'idéal serait que connecter() retourne false.

Ainsi l'erreur de connection est signalée par mail.

Est ce possible ? (peut etre en capturant les exceptions)

Merci.

[Jidefix]

Effectivement, en try/catchant la fonction "connecter", tu peux gérer les exceptions susceptibles d'être lancées par la fonction "connecter", tu peux continuer ton code juste après, même en cas d'erreur.

[gifffftane]

Qui fait la méthode connecter ? En tous les cas ce n'est à ma connaissnce pas une méthode du JDK. Si c'est toi qui la fait, si pour toi l'idéal est qu'elle renvoie false, fais le ainsi. Quel est le problème ?

[NeoGeoo]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
private FTPClient ftp = null;
 
private boolean connecter() {
        // Affichage swing
        ecran.afficher("Connexion au FTP..");
 
        // Connexion au FTP
        ftp = Ftp.connectionFTPSauv();
        ...
        ...
}

C'est un gros projet existant sur lequel je travaille (stage). Chaque fonction fait appel à une autre, il y en a 5 en tout(connecter() -> connectionFTPSauv() -> A () -> B() -> C () ).

- Dois-je faire remonter les exception(throw) à la fonction connecter et les traiter(try..catch) dans connecter () ?
- Ou traiter les exceptions là ou elles sont levées ?

Au fait après avoir amélioré le système, je suis censé faire des tests (simuler des erreurs de connection ...) et là je m'y perd!!
Donc quelle est la stratégie ?

[LittleBean]

la stratégie est la suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
try {
   // connection
}
 
catch {
  // la connection s'est mal passée
}
finally {
  // fermer la connection qu'elle se soit bien ou mal passée 
}

l'instruction finally te permet de fermer tout proprement même si ça a planté

[NeoGeoo]

la stratégie est la suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
try {
   // connection
}
catch {
  // la connection s'est mal passée
}
finally {
  // fermer la connection qu'elle se soit bien ou mal passée 
}

l'instruction finally te permet de fermer tout proprement même si ça a planté

Ok ! c'est noté.

Mais ça ne répond qu'à moitié pas à ma question (plus haut) (selon quoi est ce que je choisit de remonter l'exception ou la traiter ?)

[Jidefix]

C'est une question de conception. En général je résume la question à ça:
- Ta fonction est-elle capable de prendre les décisions pour gérer l'exception?

En clair si ta connexion ne fonctionne pas, tu voudras probablement renvoyer un message d'erreur à un utilisateur.

Dans ce cas, la fonction de connexion devra probablement laisser passer l'exception à la fonction appelante pour que celle-ci se charge de reprendre.

Sinon tu peux aussi utiliser le retour booléen de la fonction pour signaler une erreur (renvoyer false), auquel cas tu préféreras catcher l'erreur. C'est un choix.

Tu peux même faire un mix des deux en fonction de l'erreur (par exemple si c'est un problème de serveur introuvable, tu ne feras pas la même chose que pour un mauvais login).