Syntaxe plus basique - Boucles et exceptions

Cette semaine a été une de ces semaines improductives. Je n'ai pas pu beaucoup progresser dans le contenu du bootcamp, mais j'ai réussi à aborder les dernières unités théoriques de ce module :

Java, comme la plupart des langages de haut niveau dérivés du C, possède trois types fondamentaux de boucles de répétition (les fameuses boucles) : for, while et do-while.

For est utilisé lorsque l'on connaît à l'avance la taille de l'élément qui sera utilisé comme itérable (comme un tableau). Cet élément peut changer dynamiquement (comme, par exemple, la réception de données d'une API), donc vous, en tant que développeur, ne savez peut-être pas exactement combien d'éléments l'itérable aura, mais le code le saura. Sa structure de base est :

int[] numbers = {1, 2, 3, 4, 5};
for (int counter = 0; counter < numbers.length; counter++) {
    System.out.println(numbers[counter]);
}

La première partie, le compteur int = 0 est ce que nous appelons la

variable count. Il doit y avoir des noms plus jolis, mais celui-ci explique ce que ça fait. En gros, elle... fait un compte.

On l'initialise à 0 et, dans une seconde partie, on le compare à la taille des

tableau nombres. C'est ce que l'on appelle la condition. Tant que cette condition est vraie (c'est-à-dire renvoie vrai), la boucle continuera. Il ne doit pas nécessairement s'agir d'une comparaison avec un itérable, mais il est normalement utilisé de cette façon. Et enfin, nous avons le
contre-changement, qui peut être un incrément ou un décrément. Il n'est pas non plus strictement nécessaire que ces changements soient effectués un par un, mais c'est la chose la plus courante à voir.

La boucle while, en revanche, ne prévoit pas ces quantités finies d'itérations. Il vérifie si une condition est vraie et, si tel est le cas, prend des mesures. Sa structure est la suivante :

boolean podeJavascriptNoBack = false;
while (!podeJavascriptNoBack) {
    System.out.println("Tá proibido JavaScript no back-end.");
};

Ce qui se trouve entre parenthèses dans la déclaration de boucle est la

condition qui sera testée pour vérifier si elle continue ou non. Tant que le résultat de cette condition est vrai, l’action entre les accolades sera effectuée. Cette information est importante car nous pouvons en tirer quelques conclusions :

L'action
1. boucle n'aura lieu que si la condition est positive. Si dans une itération donnée la valeur de la condition change (de vrai à faux), la boucle est interrompue et l'action de ce cycle n'est pas exécutée ;
Il peut y avoir une
2. boucle qui n'effectue aucune action car la condition a été évaluée comme fausse dès la première itération ;
S'il n'y a aucune action pour changer le résultat de la condition, nous nous retrouverons face à une
3. boucle infinie.

Do-while est très similaire à while, à la différence que l'action se produit

avant de vérifier la condition. Cela signifie que la boucle effectuera au moins une action avant d'être interrompue. La syntaxe est très similaire à while :

boolean condition = true;
do {
    System.out.println("I'm inside a loop tee-hee!");
} while (condition);

De la même manière que while, s'il n'y a aucune action pour changer le résultat de la

condition, on aura affaire à une boucle infinie.

Pour avoir encore plus de contrôle sur le déroulement des boucles, il reste les mots-clés break et continue. break interrompt toute la boucle, tandis que continue n'interrompt que l'itération en cours. Par exemple :

for (int i = 0; i <= 5; i++) {
    if (i == 4) break;
    System.out.println(i); //0 1 2 3
}

Dans cet exemple, for fonctionnera jusqu'à ce que le compteur i soit supérieur ou égal au chiffre 5, et à chaque itération le compteur actuel sera imprimé sur la console. Cependant, lorsque le compteur est égal à 4, la boucle sera interrompue et les deux derniers chiffres ne seront pas imprimés.

Maintenant, supposons que vous deviez imprimer les nombres impairs de 1 à 10 dans la console. Nous pouvons utiliser continuer avec la structure suivante :

for (int i = 0; i <= 10; i++) {
    if (i % 2 == 0) continue;
    System.out.println(i); //1 3 5 7 9
}

C'est-à-dire de 0 à 10, la

boucle vérifiera si le compteur est divisible par 2 à l'aide du modulo. Si tel est le cas, la boucle passera à l'itération suivante, mais sinon, la valeur de i sera imprimée dans le terminal.

Jusqu’ici calme, non ? Passons à la gestion des exceptions.

Au cours du développement d'une application, des problèmes surviendront. En Java, il existe une distinction entre les problèmes graves, qui affectent le système ou l'environnement dans lequel se trouve l'application (erreurs) et sont normalement des conditions irrécupérables, et les problèmes plus simples, que l'application parvient à contourner d'une manière ou d'une autre (exceptions).

No caso dos errors, pode se tratar de algum problema físico (como um OutOfMemoryError), exaustão dos recursos disponíveis (como um StackOverflowError) ou até mesmo um erro da própria JVM (Internal Error). O importante notar é que, nesse caso, não tem como tratar isso. É uma situação que quebra a aplicação e normalmente a joga em um estado irrecuperável.

Mas existe uma categoria de problemas em que é possível se recuperar: as Exceptions. As exceções são problemas que podem ser capturados e devidamente tratados, para que nosso programa não quebre na cara do cliente. As exceções podem ter as mais variadas causas, que podem ser desde problemas com a infraestrutura (como leitura/escrita de dados, conexão com um banco de dados SQL etc) ou de lógica (como um erro de argumento inválido).

Para realizar o tratamento de erros, normalmente um bloco try-catch é utilizado. Essa estrutura tenta executar uma ação (descrita no bloco try) e, caso encontre alguma exceção, captura esse problema e realiza uma tratativa em cima dela (que está descrita no bloco catch). Ela segue essa sintaxe:

try {
    double result = 10 / 0; //isso vai lançar um ArithmeticException
    System.out.println(result);
} catch (Exception e) {
    System.out.println("Não é possível dividir por 0, mané.");
}

Podemos declarar vários blocos catch encadeados, para tentar granularizar as tratativas de acordo com os erros encontrados:

try {  
    int result = 10 / 0; 
    System.out.println(result);  
} catch (ArithmeticException e) {  
    System.out.println("Não é possível dividir por 0, mané.");
} catch (NullPointerException e) {
    System.out.println("Alguma coisa que você informou veio nula, bicho.");
} catch (Exception e) {  
    System.out.println("Deu ruim, irmão. Um erro genérico ocorreu: " + e.getMessage());  
}

Além disso, ao final de toda a estrutura podemos declarar um bloco de código que sempre será executado, independente do caminho que o fluxo tomou: o finally:

try {  
    int result = 10 / 0; 
    System.out.println(result);  
} catch (ArithmeticException e) {  
    System.out.println("Não é possível dividir por 0, mané.");
} catch (NullPointerException e) {
    System.out.println("Alguma coisa que você informou veio nula, bicho.");
} catch (Exception e) {  
    System.out.println("Deu ruim, irmão. Um erro genérico ocorreu: " + e.getMessage());  
} finally {
    System.out.println("Cabô.");
}

Nesse exemplo, o código vai tentar dividir 10 por 0. Em seguida, vai entrar no primeiro bloco catch e imprimir "Não é possível dividir por 0, mané." e, por fim, entrar no bloco finally e imprimir "Cabô". Independente do caminho seguido, se houve sucesso ou não no try, o finally vai ser sempre executado.

Isso é tudo? Não! Nada é simples no Java.
As exceções podem ser divididas em dois tipos: as exceções verificadas (checked exceptions) e as não verificadas (unchecked exceptions). No caso das exceções verificadas, o compilador pede para que elas sejam tratadas para evitar que condições que estão além do escopo de código possam impactar no fluxo da aplicação. Por exemplo, o banco de dados que o programa está usando pode ter tido um problema, e a conexão pode falhar. Ao invés de simplesmente mostrar o erro, o Java pede que seja feita uma tratativa, como a abaixo:

public class DatabaseExample {
    public static void main(String[] args){
        try {
            Connection conn = getConnection();
            //executa alguma ação aqui...
        } catch (SQLException e) {
            System.out.println("Não foi possível conectar ao banco de dados. Erro: " + e.getMessage());
        }
    }

    public static Connection getConnection() throws SQLExeption {
        String url = "jdbc:mysql://localhost:3306/mydatabase";
        String user = "user";
        String password = "mySuperSecretPassword"; //por favor não armazenem senhas no código

        //isso pode lançar um erro de SQL
        return DriverManager.getConnection(url, user, password);
    }
}

O método getConnection() tenta realizar a conexão com o banco de dados usando as credenciais informadas, mas se em algum momento der problema (o banco está offline, as credenciais estão erradas, a máquina está desconectada da rede etc), a exceção será lançada. O método main, que chama o getConnection(), captura essa exceção e informa ao usuário que houve um erro ao realizar a conexão, ao invés se só mostrar a stack trace.

O compilador pede que esse tratamento seja implementado para proteger a aplicação de erros além do controle do desenvolvedor, tornando o programa mais resiliente e resistente à falhas.

Já as unchecked exceptions são exceções que não precisam ser obrigatoriamente tratadas. São casos de classes cujos métodos estão sob o controle do desenvolvedor e são, de modo geral, algum tipo de erro no código (seja de lógica ou uso incorreto de alguma API). Alguns exemplos desses são os famosos IllegalArgumentException, ArrayIndexOutOfBoundsException e NullPointerException.
Isso quer dizer que, se o compilador não reclamar, eu não preciso implementar um tratamento?
Não né. Muito melhor ter uma mensagem de erro amigável para o usuário saber o que tá acontecendo do que mandar isso aqui:

Bota tudo num try-catch que é sucesso.

E, por fim, teve um módulo sobre debugging usando Intellij e Eclipse, que foi mais prático do que teórico. Contudo, não consegui apresentar as informações passadas pela instrutura para o meio textual. Um post sobre debug em Java fica pro futuro.

Os dois módulos que restam nessa unidade são práticos (finalmente!). O próximo post vai ter bastante código. Até lá!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!