[MÚSICA] [MÚSICA] Esse é o curso de orientação a objetos com Java, meu nome é Eduardo Guerra e o assunto da aula de hoje é tratamento de erro. Eu vou mostrar para vocês como não fazer o tratamento de erro. Essa aula é para mostrar algumas das abordagens comuns, que se utilizam às vezes, principalmente, linguagens estruturadas e mostrar quais são os problemas delas para que você entenda os benefícios de usar as exceções, que é o que a gente utiliza numa linguagem orientada a objeto principalmente aí Java. Está certo? Então vamos lá. O problema sobre o qual a gente vai falar aqui hoje é como é que a gente avisa paro o método que invocou outro método, onde aconteceu erro. Ou seja, eu tenho método A, eles chamam o método B e acontece erro no método B. Como eu digo para esse método A que esse erro aconteceu, para que ele saiba que alguma coisa deu errado? Então, vamos pegar esse exemplo aqui, desse método aqui, porção. Note que ele verifica aí se ele recebe ali parâmetro que chama porcento. E aí ele verifica se ele está entre 0 e 100 e aí caso não esteja, ele retorna ao -1. Ou seja, ele está dando erro, ele vai estar usando esse -1, como uma forma de indicar para quem chamou, falou assim: " olha, se você me chamar e der -1, então quer dizer que alguma coisa deu errado". Alguma coisa estava errada, se não ele faz ali o cálculo normalmente. É uma má ideia. Vamos entender o porquê fazer isso não é bom. A primeira coisa, é que às vezes fica muito confuso para quem está chamando este método e recebendo este resultado. Imagine o cara passou ali 5.000 passou a 120. Eu quero 120% de 5.000, e ele não sabe, que aquele método, por exemplo, restringe os valores da porcentagem, dizendo assim "por que eu estou recebendo -1? O que significa -1? Será que estourou?". Ele não sabe exatamente o que é que está acontecendo. Então essa estratégia de retornar valor específico pode ser ruim justamente por as pessoas não entenderem o que está acontecendo. Outro problema é que nesse caso o -1, ele pode ser valor válido. Por exemplo, se eu chamar o método com -100 e pedir 1% o resultado correto é -1. Se eu verificar: vê aí se o retorno for -1 e se for -1 quer dizer que deu erro. Não, mas espera aí, têm determinadas chamadas, têm combinações de parâmetro que o -1 é valor válido. Tá, então isso também é uma coisa que pode ser complicada. Por exemplo, se você falar assim: " eu vou retornar, se o retorno for uma string, eu vou retornar uma string erro". Mas de repente, você está pedindo pedaço da string, pode ser que a string que o cara passou, o pedaço que você quer é erro. E aí, como você vai saber se foi erro ou se foi retorno que foi aquele valor. Então nem sempre a gente consegue valor. Imagina por exemplo se o retorno for uma data ou uma classe do seu próprio software, como por exemplo pessoa. Como é que você vai, que data é que você vai retornar como uma data inválida? Que pessoa você vai retornar como uma pessoa que significa que deu erro? Não pode pegar aquele seu amigo que faz tudo errado e querer retornar ele, não é por aí. Tá certo? Então, a gente vê que é complicado fazer isso daí. Certo? Outro problema é que às vezes vários erros diferentes podem acontecer e você quer saber qual erro que foi. Então por exemplo, você quer abrir arquivo, você está fazendo processamento que exija a abertura de arquivo, esse arquivo ele pode estar, por exemplo, bloqueado, porque tem outra pessoa trabalhando com ele ou outro programa está com ele aberto, esse arquivo pode não existir, pode ser acesso negado por questões de segurança, por questões de permissão de acesso e às vezes quando você está fazendo software, você não quer saber só se deu erro. Você quer saber porque é que esse erro está acontecendo, até mesmo pra você poder falar para quem está utilizando o seu software: "olha, esse arquivo não existe". De repente, se ele não existe, você pode oferecer criar, de repente se ele está bloqueado, você pode falar para ele tentar fechar outros programas e tentar novamente. Então, depende do erro. Não é só " deu erro!", mas qual erro aconteceu. Às vezes saber qual erro é igualmente importante. E nem pense, uma coisa que eu já vi também, de você pegar uma variável global, no caso do orientada a objeto pegar aí uma variável estática e falar: " quando der erro eu vou guardar nesta variável que deu erro". Aí eu posso colocar a descrição, posso botar o que eu quiser. Isso é uma péssima ideia. A primeira coisa, vai ser aí o mesmo problema das variáveis globais. Alguém pode fazer algum procedimento, não limpar aquela variável, ou seja, você vai depender de outro método que colocou erro ali e ir lá e tirar aquele erro, depois que processar e etc. Para não ficar lixo, para que de repente você vá lá e executa alguma coisa com sucesso, você vai lá e está erro ali. Tá, não dá legal. Ou por exemplo, se você tem, está trabalhando com programação concorrente, por exemplo, você tem uma aplicação web que tem vários processos, várias requisições acessando a mesma classe e uma delas guarda o erro, todos que forem lá vão encontrar o mesmo erro lá. Então, tomar muito cuidado com essa abordagem de ficar guardando erros variáveis que a pessoa tem que ir lá e acessar. Sendo que é muito fácil também, ela simplesmente ir lá e ignorar aquele erro. Ou seja, você depende que a pessoa vá e faça uma verificação, se tem alguma coisa naquela variável para você saber se teve erro ou não, ou seja, global é o mundo chamas, não tente isso daí. Bom, o Java e várias outras linguagens usa mecanismo de exceções para fazer o tratamento de erro. Só que eu vou deixar para explicar isso para vocês na próxima aula. Tá? Hoje a gente viu aqui o tratamento de erro, entendeu porque determinadas abordagens não funcionam bem, que tem cenários que elas não funcionam mesmo, certo? E isso aí vai servir como motivação quando você for ver as exceções, você já vai entender porque é que o jeito, o jeitão que a gente dava ali na programação estruturada, porque é que ele não dá muito certo. Certo? Muito obrigado! [MÚSICA]
