Nous avons atteint le deuxième défi de conception de ce module initial, dernière tâche avant de passer au module Programmation Orientée Objet.
J'avoue que j'ai trouvé ce défi un peu idiot et que cela aurait pu être un défi de code sans aucun problème, mais ce n'est pas grave.
Le système doit recevoir deux paramètres via le terminal qui représenteront deux entiers, avec ces deux nombres vous devez obtenir le nombre d'interactions (pour) et imprimer les nombres incrémentés dans la console (System.out.print), par exemple :
- Si vous passez les nombres 12 et 30, alors nous aurons une interaction (pour) avec 18 occurrences pour imprimer les nombres, exemple : "Impression du chiffre 1", "Impression du chiffre 2" et ainsi de suite.
- Si le premier paramètre est SUPÉRIEUR au deuxième paramètre, vous devez lever l'exception personnalisée appelée ParametrosInvalidosException avec le deuxième message : "Le deuxième paramètre doit être supérieur au premier"
Étapes suggérées :
- Créer le projet DesafioControleFluxo
- Au sein du projet, créez la classe Contador.java pour réaliser tout le codage de notre programme.
- Dans le projet, créez la classe ParametrosInvalidosException qui représentera l'exception métier dans le système.
Ce n'est pas, comme vous pouvez le constater, la chose la plus complexe au monde mais cela ouvre des possibilités intéressantes.
Nous pouvons commencer par la fin et créer l'exception personnalisée (je veux dire, après avoir créé le projet, à droite) :
//InvalidParametersException.java public class InvalidParametersException extends Exception { public InvalidParametersException() { super(); } }
C'est le moyen le plus simple de définir une exception personnalisée. Nous créons une classe (et, suivant un modèle de dénomination, nous ajoutons le suffixe Exception) qui s'étend de Exception lorsqu'il s'agit d'une exception vérifiée ou de RuntimeException, si elle n'est pas cochée (exception non cochée). Ensuite, nous définissons le constructeur de classe en fonction du comportement que nous souhaitons que notre exception ait. Dans ce cas, elle ne fera pas grand chose, alors améliorons-la.
Oh Lucas, mais qu'est-ce qu'un constructeur de classe ?? Tu n'en as jamais rien dit !!1!
On n'a pas encore vraiment mentionné ce qu'est un constructeur. Le prochain module, Orientation objet, devrait combler ce manque de connaissances. Retiens tes émotions, animal.
Dans le cas de notre exception, j'ai décidé qu'il s'agissait d'une exception vérifiée (c'est-à-dire qu'elle doit être gérée lorsque la méthode qui la lance est utilisée) pour garantir que la règle métier Si le premier paramètre est SUPÉRIEUR à le deuxième paramètre, vous devez lancer l'exception personnalisée appelée ParametrosInvalidosException avec le deuxième message : "Le deuxième paramètre doit être supérieur au premier" est respecté et il y a une gestion des erreurs afin de ne pas casser l'application
.Pour avoir plus de flexibilité dans la gestion, nous pouvons définir des constructeurs supplémentaires dans l'Exception, chacun faisant quelque chose de différent :
// InvalidParametersException.java public class InvalidParametersException extends Exception { private static final String DEFAULT_MESSAGE = "Um ou mais argumentos são inválidos."; public InvalidParametersException() { super(DEFAULT_MESSAGE); } public InvalidParametersException(String message) { super(message); } public InvalidParametersException(String message, Throwable cause) { super(message, cause); } public InvalidParametersException(Throwable cause) { super(DEFAULT_MESSAGE, cause); }}
Jetons un regard calme à cette chose.
Nous déclarons la classe InvalidParametersException en étendant la classe Exception. Cela signifie, comme je l'ai mentionné ci-dessus, que toute classe qui appelle la méthode qui lève cette exception doit implémenter un traitement pour celle-ci.
Ensuite, nous déclarons la constante DEFAULT_MESSAGE, en lui attribuant "Un ou plusieurs arguments ne sont pas valides.". Comment sait-on que c'est une constante ? En raison du mot réservé final et de l'utilisation de SCREAMING_SNAKE_CASE, un modèle courant pour désigner des constantes. Cette valeur sera affichée si l'exception est levée sans arguments, comme défini dans le premier constructeur : elle appelle le constructeur de la superclasse (dans ce cas, l'Exception) en passant DEFAULT_MESSAGE. Ainsi, si nous avons un paramètre invalide, si un message personnalisé n'est pas défini, l'erreur affichée sera "Un ou plusieurs arguments ne sont pas valides.".
Le deuxième constructeur permet de lever l'exception avec un message personnalisé. En d’autres termes, nous pouvons remplacer les messages d’erreur standards par un message personnalisé. Par exemple, au lieu d'afficher quelque chose comme Exception dans le thread "main" java.lang.NullPointerException, nous pouvons afficher Vous m'avez demandé d'accéder à quelque chose qui était nul. Est-ce que ça va, mon ami ?.
Les deux derniers ont un argument différent, la cause. Il s'agit d'un Throwable (un throwable) et est utilisé pour relancer une exception. Par exemple, supposons que dans certaines de vos applications, il y ait un point qui doit faire une division entre deux données saisies par l'utilisateur et le dénominateur (vous vous en souvenez des classes de fractions ?) finit par être 0.
Lembra quando esse formato de meme era popular? Bons tempos aqueles...
Isso vai lançar uma ArithmeticException, mas o que você quer na verdade é usar sua exceção customizada novinha, que deu tanto duro para criar. Aí você pode fazer algo assim:
try { Scanner sc = new Scanner(System.in); int num1 = sc.nextInt(); //10 int num2 = sc.nextInt(); //0 int result = num1 / num2; //OH SHI- } catch (ArithmeticException ex) { throw new InvalidParametersException("Não pode dividir por 0, bicho", ex); }
Ou seja, o bloco try-catch captura a ArithmeticException, pega o motivo de ter sido lançada e passa para a exceção customizada, que vai disponibilizar uma mensagem mais amigável para o usuário E mostrar a causa dessa pataquada toda. A pilha de execução (stack trace) para essa situação poderia ser mais ou menos assim:
Exception in thread "main" InvalidParametersException: Não pode dividir por 0, bicho at Main.main(Main.java:10) Caused by: java.lang.ArithmeticException: / by zero at Main.main(Main.java:9)
Temos nossa mensagem amigável na primeira linha da pilha mas também temos o ponto exato onde as coisas deram errado, para termos uma depuração mais rápida.
Nossa, quanta coisa. E ainda nem entramos no método propriamente dito.
Aqui eu tenho que fazer uma mea-culpa: Eu reclamei a um tempo atrás de como na documentação da classe Scanner mostra que existe um método específico para capturar cada tipo primitivo e fui induzido a achar que esse era o único jeito de fazer isso. Mas conversando no Discord da Orange Juice, meu chegado Claudio me disse que tem um jeito muito mais simples:
Ou seja, eu fiquei reclamando reclamando reclamando mas aparentemente dá pra fazer exatamente como no C#, como eu falei que era melhor. Claro, não dá pra aceitar tudo cegamente, então eu fui fazer um teste:
public static void main(String[] args) { Scanner scanner = new Scanner(System.in); System.out.print("Insira o primeiro número: "); int num1 = Integer.parseInt(scanner.nextLine()); System.out.print("Insira o segundo número: "); int num2 = Integer.parseInt(scanner.nextLine()); System.out.println("O primeiro número foi: " + num1 + " e o segundo foi: " + num2); }
Não é que deu certo, gente?
Eu to me sentindo bem mal agora, não fiz a coisa mais simples antes de começar a reclamar... Que burro, dá zero pra mim.
Muito bem. Me desculpe, menino Java.
Isto posto, podemos começar a desenvolver nosso método de contagem. A classe Counter vai ter dois métodos: o counter, que vai conter a lógica da contagem e o main, que vai chamar o contador e tratar as exceções que surgirem. Vamos começar com o counter:
public class Counter { public static void main(String[] args) {} //por enquanto esse método segue vazio public static void count(int num1, int num2) throws InvalidParametersException { if (num1 < 0 || num2 < 0) throw new InvalidParametersException(); if (num1 > num2) throw new InvalidParametersException("O primeiro argumento deve ser maior que o segundo"); int counter = num2 - num1; System.out.printf("Vou imprimir todos os números de 1 até %d.%n", counter); for (int i = 1; i <= counter; i++) { System.out.printf("Imprimindo o número %d%n", i); } } }
Declaramos o método counter, que é público e não tem retorno (podemos ter certeza por conta do void ali). Além disso, esse método é estático, então não precisamos instanciar a classe para podermos usá-lo. Ele recebe dois argumentos do tipo int, num1 e num2 -- criatividade é a alma do negócio. Por fim, podemos ver que esse método lança a nossa maravilhosa exceção InvalidParametersException, o que vai obrigar o método main a realizar algum tipo de tratamento em cima dela.
Para garantir que as regras de negócio vão ser respeitadas, o método faz duas verificações:
Depois disso, é realizada a subtração que vai montar o loop. Feita essa conta, é impressa no console uma mensagem informando que a aplicação irá mostrar todos os números de 1 até o resultado.
E aqui vem mais uma particularidade do Java: a falta de interpolação de strings. Eu me acostumei a escrever
const variable = variable; let sentence = `I'm a sentence that uses a ${variable}!`;
ou
string name = "John Doe"; string sentence = $"My name is {name}.";
que é até esquisito imaginar uma linguagem moderna que não utiliza isso.
Para ficar melhor (e evitar usar a concatenação com aquela sintaxe horrorosa), descobri que poderia formatar a mensagem com o método String.format(), da mesma forma que a formatação de string do C. E assim como no C, existe a possibilidade de já formatar a string usando o método print. Em vez de usar o .println() para imprimir uma string e já pular uma linha (o ln significa que caractere para newline será adicionado no final), o método .printf() formata a mensagem de acordo com o placeholder informado.
Existem muitos placeholders que podem ser utilizados, mas os mais comuns são %s para string, %d para int, %f para números de ponto flutuante (como double e float) e %f para data/hora. Porém esse método não cria uma quebra de linha então caso seja necessário, é preciso adicionar o caractere %n para uma nova linha.
Aí, por último, fazemos nosso laço for, sem grandes mistérios. Inicializamos o contador do loop em 1 e o instruímos a repetir a tarefa até o chegar no resultado final, incrementando o valor do contador de um em um. A cada volta imprimimos o valor do contador atual, cumprindo, desse modo, o requisito do desafio.
Beleza, criamos o método que vai realizar a ação que precisamos. Agora, o que falta é chamar a função e executá-la em algum lugar, né? Vamos fazer isso no método main da nossa classe Counter:
public class Counter { public static void main(String[] args) { try { Scanner scanner = new Scanner(System.in); System.out.println("Insira dois números e a aplicação imprimirá a diferença entre eles, linha a linha."); System.out.print("Insira o primeiro número: "); int num1 = Integer.parseInt(scanner.nextLine()); System.out.print("Insira o segundo número: "); int num2 = Integer.parseInt(scanner.nextLine()); count(num1, num2); } catch (InvalidParametersException e) { System.out.println(e.getMessage()); } } public static void count(int num1, int num2) throws InvalidParametersException { /* lógica descrita acima */ }
Aqui não tem nada muito excepcional: Instanciamos um novo scanner e, seguindo a dica valiosa do Cláudio, pedimos ao usuário que insira dois números. Esses números são capturados como string e imediatamente convertidos em int. Com esses dados, chamamos a função count passando os dois números como parâmetros e, caso alguma exceção seja lançada, uma mensagem de erro será exibida no console.
Show, mas será que funciona?
Aparentemente sim. ✌️
Mas o que acontece se, por exemplo, algum usuário espírito de porco curioso inserisse um número muito grande em um dos campos? Será que a aplicação daria conta do recado?
Bom, não né. O int, destino da conversão da string nos inputs, aloca 32 bits de memória para cada variável. Isso quer dizer, na prática, que o valor máximo que ele pode armazenar é 2147483647 (e o menor, -2147483648). Quando o número alvo extrapola esse limite, essa exceção NumberFormatException é lançada.
Para solucionar isso, poderíamos mudar o tipo de destino de int para long, mas o problema da limitação ainda se mantém. Claro que é bem mais difícil que alguém indique um número grande como o long (cujo valor máximo é 9223372036854775807), mas é sempre bom não dar chance pro azar. Por isso, a melhor coisa é adicionar algum tipo de limitação e informar ao usuário que ele tá maluco precisa informar um número dentro do intervalo esperado.
Além disso, a aplicação encerrar quando encontra um erro é meio chato. O ideal seria que ela voltasse a iniciar caso encontrasse um erro, até que os inputs fossem inseridos de maneira correta.
Podemos resolver adicionando um novo catch no nosso try e envolvendo a aplicação toda em um laço while:
public class Counter { public static void main(String[] args) { while (true) { try { Scanner scanner = new Scanner(System.in); System.out.println("Insira dois números e a aplicação imprimirá a diferença entre eles, linha a linha."); System.out.print("Insira o primeiro número: "); int num1 = Integer.parseInt(scanner.nextLine()); System.out.print("Insira o segundo número: "); int num2 = Integer.parseInt(scanner.nextLine()); count(num1, num2); break; } catch (InvalidParametersException e) { System.out.println(e.getMessage()); } catch (NumberFormatException e) { System.out.println("Um dos números informados estão acima da capacidade de processamento desta aplicação. Por favor, tente novamente com um número menor."); } } } public static void count(int num1, int num2) throws InvalidParametersException { /* lógica descrita acima */ }
A primeira coisa que fizemos foi, então, envolver todo o try-catch em um laço while, e definimos a condição como true. Ou seja, enquanto true for... verdadeiro, o laço se repetirá.
Fizemos um famigerado loop infinito, a perdição de todo processador.
Em vez de colocarmos a condição para parada do while na sua definição, apenas colocamos um break ao final da chamada ao método count(); desse modo, se não houver alguma exceção lançada, o loop será interrompido.
Ao final da chamada, definimos mais um bloco catch, capturando a exceção NumberFormatException e passando uma mensagem de erro mais fácil de ser compreendida. Bora testar pra ver se está tudo certo?
Bom demais.
Agora, a única coisa que falta é chamar o método Counter.main() na classe Main. Pode ser redundante, mas eu prefiro deixar bem separadinhas e explicadas as coisas.
public class Main { public static void main(String[] args) { Counter.main(args); } }
É isso aí, pessoal. Obrigado pela paciência e por ter lido esse post gigantesco.
O repositório desse projetinho pode ser encontrado aqui. Até a próxima!
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!