Discussion :

[nzoway]

Bonjour à toutes et à tous,
je souhaiterais développer une application server/client TCP sur Android Studio.
Étant débutant j'ai suivi quelques tutos, mais depuis quelques jours je sèche complètement sur une erreur quand je tape la ligne ci dessous:

InetAddress serverAddress = InetAddress.getByName("127.0.0.1")


La portion "InetAddress.getByName("127.0.0.1")" se surligne en rouge, m'indiquant un joli "Android java.net.UnknownHostException", tout ça sans compiler et tester le code, ce qui est étonnant. J'ai ajouté les autorisations nécessaires dans le XML de l'app et j'ai tenté de supprimer le virtual device mais sans succès.

Est ce que j'ai raté quelque chose? Quelqu'un aurait une idée ?
Merci d'avance

[joel.drigo]

Salut,

Toutes les méthodes qui soulèvent une exception explicitement, c'est-à-dire qui ont un throws dans leur définition, nécessitent un traitement de cette exception dans le code, soit en utilisant un try/catch, soit en envoyant l'exception vers une autre méthode appelante, en ajoutant un throws sur la méthode courante.

C'est le cas de public static InetAddress getByName​(String host) throws UnknownHostException. Ton éditeur t'indique juste, par ce souligné rouge, que ton code ne passera pas la compilation, et, d'ailleurs, il doit t'indiquer également (dans un tooltip en survolant la partie soulignée entre autres) le problème exact et peut même te proposer des quickfixes.

[salfai]

Ce message indique que ce code peut lever une exception de type UnknownHostException qu'il faut catcher (comme l'indique normalement ton IDE quand tu met la souris sur la partie rouge "unhandled exception ..."). Il faut faire cela pour que l'application ne plante pas en cas d'erreur.

Code :

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

1
2
3
4
5
6
7
 
InetAddress serverAddress;
        try {
            serverAddress = InetAddress.getByName("127.0.0.1");
        } catch (UnknownHostException e) {
            e.printStackTrace();
        }

Tu peut générer automatiquement le try/catch en mettant le curseur sur la partie rouge et en appuyant sur ALT+ENTREE (du moins sur Android Studio), puis en choisissant l'option "Surround with try catch".

EDIT : joel.drigo a été plus rapide

EDIT 2 : un article intéressant : https://anisfrikha.developpez.com/tu...va/exceptions/

[joel.drigo]

Code :

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

1
2
3
4
5
6
7
 
InetAddress serverAddress;
        try {
            serverAddress = InetAddress.getByName("127.0.0.1");
        } catch (UnknownHostException e) {
            e.printStackTrace();
        }

Attention à cette structure de code. Premièrement, serverAddress ne sera pas initialisée en cas d'exception, et, donc, le code qui suit qui pourrait chercher à exploiter la valeur de cette variable ne compilera pas (une variable doit avoir une valeur pour être "lue"). D'une manière générale, une simple trace n'est pas suffisant pour traiter une exception : le code suivant ayant besoin de cette variable n'aura pas un fonctionnement cohérent. Lorsqu'il y a exception, soit on sait ce qu'on doit faire pour réagir à cette exception et on le fait. Soit on ne sait pas et on renvoie à l'appelant (il doit y avoir forcément un bout de code qui sait comment réagir à l'exception).

A noter que si on ne sait pas quoi faire pour réagir à l'exception, mais qu'on ne veut pas imposer à l'appelant de la traiter explicitement, on peut l'encapsuler dans une RuntimeException (et particulièrement pour une IOException, dans un UncheckedIOException). C'est un peu jeter le truc sous le tapis, et on risque de planter un thread, voire l'application (si on ne traite pas au final l'exception dans un UncaughtExceptionHandler, ou un catch spécifique), mais ça peut simplifier les choses.

[nzoway]

C'est ce que je voulais tester ce soir, en ajoutant un try/catch mais j'aurais utilisé la même méthode que celle proposé par salfai, seulement après ce que j'ai pu lire cela pourrait bloquer l'exécution du code.
Alors comment faire?
En plus comme est ce possible de générer une exception sans exécuter le code? Pour moi c'est comme faire caller sa voiture sans démarrer le moteur ^^
Est ce du "préventif" de la part d'Android Studio?

Je suis désolé si je pose des questions stupides mais j'ai très rarement eu besoin d'utiliser des try/catch, et à chaque fois c'était durant l'exécution du code, donc je savais exactement pourquoi ça clochait et comment le corriger.

[joel.drigo]

mais j'ai très rarement eu besoin d'utiliser des try/catch, et à chaque fois c'était durant l'exécution du code, donc je savais exactement pourquoi ça clochait et comment le corriger.

C'est bien à l'exécution du code que l'exception sera soulevée le cas échéant. Seulement, on n'est obligé de traiter le problème dans le code, pour qu'il compile, et ton éditeur/EDI te le signale à l'édition du code.

C'est ce que je voulais tester ce soir, en ajoutant un try/catch mais j'aurais utilisé la même méthode que celle proposé par salfai, seulement après ce que j'ai pu lire cela pourrait bloquer l'exécution du code.

Le try/catch ne bloque pas nécessairement l'exécution du code. D'ailleurs, il vaudrait mieux qu'il ne le fasse pas. Je disais juste que le code qu'indiquait salfai ne compilera pas si on traite la valeur de serverAddress dans ou après le catch.

Code :

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

1
2
3
4
5
6
7
8
9
 
InetAddress serverAddress;
try {
            serverAddress = InetAddress.getByName("127.0.0.1"); // j'ai pas dit que c'était pas très logique de passer une adresse dans une méthode qui résous un nom en adresse parce que c'était un autre problème
} catch (UnknownHostException e) {
            e.printStackTrace();
}
if ( serverAddress.isAnyLocalAddress() ) { // ne compile pas, parce que serverAddress n'a potentiellement pas de valeur !!!
}

Parce que que le compilateur n'en veut pas de variable qui n'a potentiellement pas de valeur. Rien à voir d'ailleurs avec les exceptions, les try/catch et les throws.
Le code suivant ne compile pas :

Code :

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

1
2
String s;
System.out.println(s);

Alors comment faire?

Et bien là, ça dépend de plein de choses et je dirais pour faire court qu'il n'y a que toi qui le sait. Parce que ça dépend de à quoi ça sert ce bout de code. On peut tout simplement arrêter la méthode :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public boolean faireUnTruc() {
InetAddress serverAddress;
try {
            serverAddress = InetAddress.getByName("hostname"); 
} catch (UnknownHostException e) {
        // ici on peut écrire dans le logcat qu'il y'a eu un problème et lequel et qu'on n'a pas pu faire le truc à cause de ça
        return false;
}
// continuer de faire ce qu'on veut faire avec l'adresse
return true;
}

et dans l'appelant :

Code :

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

1
2
3
4
5
6
if( faireUnTruc() ) {
   // on a fait le truc, alors on fait ce qu'on veut
}
else {
  // on n'a pas fait le truc, alors on fait, un autre truc, comme, par exemple, afficher un message à l'utilisateur du genre "y'a un problème : on n'a pas pu faire le truc"
}

On peut faire autre chose (fallback ou fall-over), utiliser une autre valeur par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void faireUnTruc() {
InetAddress serverAddress = null;
try {
            serverAddress = InetAddress.getByName("hostname"); 
} catch (UnknownHostException e) {
   try {
            serverAddress = InetAddress.getByName("unautrehostname");  
   } catch (UnknownHostException e) {
        // ici on peut écrire dans le logcat qu'il y'a eu un problème et lequel et qu'on n'a pas pu faire le truc à cause de ça
   }
}
if ( serverAddress!=null ) {
   // continuer de faire ce qu'on veut faire avec l'adresse
}
}

etc.

En plus comme est ce possible de générer une exception sans exécuter le code? Pour moi c'est comme faire caller sa voiture sans démarrer le moteur ^^
Est ce du "préventif" de la part d'Android Studio?

A quoi ça servirait de générer l'exception sans exécuter le code ? Même en exécutant le code ? Une exception c'est justement quelque chose qui ne se passe jamais sauf quand il y a un problème. Genre tu te connectes à un serveur qui n'est pas accessible : normalement, y'a pas de raison qu'il ne le soit pas, mais ça peut arriver. Dans ce cas, on ne peut pas faire toutes les requêtes qu'on a besoin de faire, donc on prévient par exemple l'utilisateur que le serveur n'est pas disponible, et qu'il réessaye plus tard. Après à lui de voir, si c'est à lui de regarder pourquoi le serveur ne répond pas ou s'il doit appeler je ne sais qui pour le voir, ou autre...

A noter qu'il y a des exceptions qui n'arrivent que si le programmeur s'est vautré. Malheureusement, dans le cas d'un throws, il est obligé de traiter l'exception alors qu'il sait pertinemment qu'elle n'aura jamais lieu, ou qu'il y a très peu de risque en tout cas.
Genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
package machin.truc;
public class Bidule {
     public static void method() {
           try {
                Class.forName("machin.truc.Bidule");
           }
           catch(ClassNotFoundException e) {
                System.out.println("Toi tu n'as vraiment pas de bol !");
           }
     }
}

Et rien à voir avec Android Studio. Quant à être préventif, je ne sais pas, d'une certaine manière oui (dans le fait que c'est parce que ça plantera à la compile), d'une autre non (parce qu'il faut le faire de tout façon).

Au pire, tu peux faire :

Code :

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

1
2
3
4
5
6
7
public void faireUnTruc() {
try {
   InetAddress serverAddress = InetAddress.getByName("hostname"); 
   // continuer de faire ce qu'on veut faire avec l'adresse
} catch (UnknownHostException e) {
}
}

Simplement, y'a du code qui pourrait ne pas s'exécuter (si l'exception se soulève) et tu pourrais ne pas même le savoir (on n'affiche aucun log, on ignore simplement l'exception). On ne fait normalement jamais ça, un catch sans code, justement, au moins pour savoir qu'il y a un truc qui s'est mal passé, en traçant à minima.