Chegamos ao segundo desafio de projeto desse módulo inicial, a última tarefa antes de passarmos para o módulo de Programação Orientada a Objetos.
Confesso que achei esse desafio meio besta e podia ser um desafio de código sem problemas, mas tudo bem.
O sistema deverá receber dois parâmetros via terminal que representarão dois números inteiros, com estes dois números você deverá obter a quantidade de interações (for) e realizar a impressão no console (System.out.print) dos números incrementados, exemplo:
- Se você passar os números 12 e 30, logo teremos uma interação (for) com 18 ocorrências para imprimir os números, exemplo: "Imprimindo o número 1", "Imprimindo o número 2" e assim por diante.
- Se o primeiro parâmetro for MAIOR que o segundo parâmetro, você deverá lançar a exceção customizada chamada de ParametrosInvalidosException com a segunda mensagem: "O segundo parâmetro deve ser maior que o primeiro"
Sugestão de passos:
- Crie o projeto DesafioControleFluxo
- Dentro do projeto, crie a classe Contador.java para realizar toda a codificação do nosso programa.
- Dentro do projeto, crie a classe ParametrosInvalidosException que representará a exceção de negócio no sistema.
Não é, como podem ver, a coisa mais complexa do mundo mas abre algumas possibilidades interessantes.
Podemos começar pelo final e criando a exceção customizada (quero dizer, depois de criar o projeto né):
//InvalidParametersException.java public class InvalidParametersException extends Exception { public InvalidParametersException() { super(); } }
Esse é o jeito mais simples de definir uma exceção customizada. Criamos uma classe (e, seguindo um padrão de nomenclatura, colocamos o sufixo Exception) que estende de Exception quando ela for uma exceção verificada (checked exception) ou de RuntimeException, se ela não for verificada (unchecked exception). Aí definimos o construtor da classe de acordo com o comportamento que queremos que nossa exceção tenha. Nesse caso ela não vai fazer muita coisa, então vamos dar uma melhorada nela.
Ai Lucas mas o que é um construtor de classe?? Você nunca disse nada sobre isso!!1!
Realmente, não foi mencionado ainda o que é um construtor. O próximo módulo, de Orientação a Objetos, deve corrigir essa lacuna de conhecimento. Segura a emoção, bicho.
No caso da nossa exceção, eu decidi que ela deve ser uma exceção verificada (ou seja, ela deve ser tratada quando o método que a lança é utilizado) para garantir que a regra de negócio Se o primeiro parâmetro for MAIOR que o segundo parâmetro, você deverá lançar a exceção customizada chamada de ParametrosInvalidosException com a segunda mensagem: "O segundo parâmetro deve ser maior que o primeiro" seja respeitada e haja um tratamento de erro a fim de não quebrar a aplicação.
Para termos mais flexibilidade na hora do tratamento, podemos definir construtores adicionais na Exception, cada um fazendo uma coisa diferente:
// 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); }}
Vamos olhar com calma esse troço.
Declaramos a classe InvalidParametersException estendendo a classe Exception. Isso quer dizer, como já mencionei acima, que qualquer classe que chame o método que lance essa exceção precisa implementar um tratamento para ela.
Em seguida, declaramos a constante DEFAULT_MESSAGE, atribuindo "Um ou mais argumentos são inválidos." a ela. Como sabemos que é uma constante? Por causa da palavra reservada final e do uso do SCREAMING_SNAKE_CASE, um padrão comum para designar constantes. Esse valor vai ser exibido caso a exceção seja lançada sem argumentos, como definido no primeiro construtor: Ele chama o construtor da superclasse (no caso, a Exception) passando DEFAULT_MESSAGE. Então no caso de termos um parâmetro inválido, se uma mensagem customizada não for definida, o erro mostrado será "Um ou mais argumentos são inválidos.".
O segundo construtor permite que a exceção seja lançada com uma mensagem personalizada. Ou seja, podemos substituir as mensagens de erro padrão com alguma mensagem customizada. Por exemplo, em vez de mostrar algo como Exception in thread "main" java.lang.NullPointerException, podemos exibir Você me instruiu a acessar algo que estava nulo. Tá tudo bem, amigo?.
Os dois últimos tem um argumento diferenciado, o cause. Ele é um Throwable (um lançável) e é utilizado para relançar uma exceção. Por exemplo, vamos supor que em alguma aplicação sua exista um ponto que precise fazer uma divisão entre dois dados informados pelo usuário e o denominador (lembra dele das aulas de fração?) acaba sendo 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 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; iDeclaramos 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:
- Checa se qualquer um dos números é negativo e, em caso positivo lança uma exceção informando ao usuário que um ou mais argumentos são inválidos;
- Essa checagem, apesar de não ter sido pedida, é para garantir que não haveria resultados esquisitos na subtração feita. Eu não queria, por exemplo, ter que lidar com resultados negativos.
- Checa se o primeiro número é maior do que o segundo. Se sim, lança uma exceção orientando o usuário que o segundo número (o numerador da divisão) deve ser maior.
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árioespírito de porcocurioso 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 queele tá malucoprecisa 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!
免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。
Copyright© 2022 湘ICP备2022001581号-3