Évitez les pièges de la programmation Java : 4 erreurs courantes à ne pas répéter

Introduction

La programmation Java est une tâche complexe qui nécessite une grande attention aux détails. Dans ce billet, nous allons explorer quatre erreurs courantes que les développeurs font souvent et qui peuvent avoir des conséquences graves sur la qualité de leur code.

Erreur 1 : Utiliser null pour représenter une valeur vide

L’exemple suivant est typique d’une erreur que l’on voit souvent :

public String joinStrings(String a, String b) {
    if (a == null) {
        a = "";
    }
    if (b == null) {
        b = "";
    }
    return a + ": " + b;
}

À première vue, cela semble une bonne pratique pour éviter les NullPointerExceptions. Mais est-ce vraiment ainsi ?

Prenons quelques moments pour analyser la situation.

Qu’est-ce que signifie “null” pour “a” ou “b”? Nous savons déjà que nous pouvons représenter un string vide en utilisant le caractère de fin de chaine ("").

Donc, est-ce que null a une valeur différente de "" ? Si oui, alors cela pose problème, car nous avons deux façons de représenter un string vide.

Et comment l’auteur a-t-il obtenu ce null ? Est-ce qu’il s’agit d’un champ non initialisé ou d’une erreur de programmation ?

Si c’est une erreur, il faudrait la corrigée et ne pas “faire bonne mine” en utilisant un string vide au lieu.

Erreur 2 : Utiliser null pour représenter un tableau ou une collection vide

Certains développeurs pensent que l’utilisation de null pour représenter un tableau ou une collection vide peut aider à économiser de la mémoire. Mais est-ce vraiment efficace ?

Considérons deux exemples :

Le premier exemple montre comment on devrait coder une méthode pour additionner les éléments d’un tableau :

public int sum(int[] values) {
    int somme = 0;
    for (int valeur : values) {
        somme += valeur;
    }
    return somme;
}

Et voici le deuxième exemple, où nous utilisons null pour représenter un tableau vide :

public int sum(int[] values) {
    if (values != null) {
        int somme = 0;
        for (int valeur : values) {
            somme += valeur;
        }
        return somme;
    } else {
        return 0;
    }
}

Comme vous pouvez le voir, la deuxième version est plus compliquée et plus fragile. Si nous utilisons cette méthode dans plusieurs endroits de notre code, nous devons faire attention à tester si les tableaux sont null avant d’utiliser leur contenu.

Erreur 3 : Ne pas vérifier si un flux d’entrée-sortie n’est pas initialisé avant de le fermer

Lorsque nous utilisons des flux d’entrée-sortie, il est important de les fermer correctement pour éviter les fuites de mémoire. Mais qu’est-ce qui se passe si la création du flux provoque une exception ?

Considérons l’exemple suivant :

void writeNullBytesToAFile(int count, String filename) throws IOException {
    FileInputStream in = null;
    try {
        in = new FileInputStream(filename);
        for (; count > 0; count--) {
            in.read();
        }
    } finally {
        if (in != null) {
            in.close();
        }
    }
}

Dans cet exemple, si la création du flux provoque une exception, alors in sera null et le code dans le bloc finally provoquera un NullPointerException.

Pour éviter cela, il faut vérifier si le flux est null avant de le fermer :

void writeNullBytesToAFile(int count, String filename) throws IOException {
    FileInputStream in = null;
    try {
        in = new FileInputStream(filename);
        for (; count > 0; count--) {
            in.read();
        }
    } finally {
        if (in != null) {
            in.close();
        }
    }
}

Et mieux encore, nous pouvons utiliser la méthode try-with-resources pour automatiser le fermeture du flux :

void writeNullBytesToAFile(int count, String filename) throws IOException {
    try (FileInputStream in = new FileInputStream(filename)) {
        for (; count > 0; count--) {
            in.read();
        }
    }
}

Erreur 4 : Renvoyer null au lieu de lancer une exception

Certains développeurs préfèrent renvoyer null plutôt que de lancer une exception. Mais est-ce vraiment efficace ?

Considérons l’exemple suivant :

public Reader getReader(String pathname) {
    try {
        return new BufferedReader(new FileReader(pathname));
    } catch (IOException ex) {
        System.out.println("Open failed: " + ex.getMessage());
        return null;
    }
}

Dans cet exemple, nous renvoyons null si l’ouverture du fichier provoque une exception. Mais qu’est-ce qui se passe ensuite ? Le code appelant doit tester si le Reader est null avant de l’utiliser.

Et pire encore, nous utilisons un try-catch-finally pour fermer le flux, ce qui peut causer des problèmes de ressources non libérées.

Pour éviter cela, il vaut mieux lancer une exception que de renvoyer null :

public Reader getReader(String pathname) {
    try {
        return new BufferedReader(new FileReader(pathname));
    } catch (IOException ex) {
        throw new RuntimeException("Impossible d'ouvrir le fichier", ex);
    }
}

Conclusion

En conclusion, ces quatre erreurs courantes sont des pièges que les développeurs doivent éviter pour écrire du code de qualité. En comprenant bien les implications de chaque erreur et en adoptant les bonnes pratiques, nous pouvons écrire du code plus robuste et plus efficace.

Suggested next steps

• Re-examinez votre code pour identifier ces erreurs courantes.
• Prenez des mesures pour éviter ces erreurs dans vos futurs projets.
• Expérimentez les bonnes pratiques présentées dans cet article pour améliorer la qualité de votre code.