Programação Java: Erros Jogando

É essencial que o seu código Java faz todos os esforços para corrigir um problema. No entanto, há momentos em que o seu código simplesmente não tem informação suficiente, recursos, direitos, ou algum outro requisito para corrigir um problema.

Quando isso acontece, o código gera um erro usando um objeto de exceção. O termo exceção é adequado, porque deve ser a exceção à regra, ao invés do primeiro ato que o aplicativo executa. Mesmo assim, as aplicações encontrar erros que exigem medidas excepcionais, e as seções a seguir descrevem como lidar com esses tipos de situações.

Jogando erros durante a condições excepcionais

Para a prática, você pode criar um aplicativo que pode gerar vários tipos de erros. Normalmente, você não iria lançar um erro se um valor está na faixa errada - você exibir uma mensagem diretamente para o usuário em seu lugar. No entanto, você pode criar um exemplo que demonstra como jogar e pegar um erro de dentro de um método.

Passando erros ao chamador

Muitos exemplos de código que você começam com está apenas começando a chegar ao ponto onde você está chamando métodos da main (). O método main () é sempre o nível mais alto de sua aplicação. Como você chamar os métodos, os métodos que você chama de níveis adicionais de formulário.

Por exemplo, um método chamado de main () seria no segundo nível da sua aplicação. Se este método tinha a chamada para outro método, este método seria no terceiro nível, e assim por diante. A maioria das aplicações são compostas de muitos níveis de chamadas.

Na verdade, quando você vê uma tela de exceção, ele realmente exibe uma lista dos métodos que chamou o método atual em um formato chamado pilha de chamadas.

A chamada stackis uma lista de métodos e a ordem em que eles são chamados por outros métodos. Sabendo a pilha de chamadas pode ajudar a localizar a origem de um erro potencial quando isso não acontece ao nível atual do aplicativo.

Manipulação de erros é uma parte essencial da boa prática de programação. Se você quiser aplicações robustas que não deixam de funcionar constantemente, você precisa fornecer um bom tratamento de erros. No entanto, tentando lidar com um erro quando você não tem informações suficientes para lidar com esse erro também é um problema.

Quando seu código tenta corrigir um erro em um nível muito baixo, ele esconde o erro de um nível que poderia corrigi-lo. Sim, você quer corrigir um erro no nível mais baixo possível, mas não à custa de proporcionar uma reparação que poderia realmente acabar escondendo algo mais sério.

Quando você achar que um determinado nível de um aplicativo não tem os recursos necessários, informação, privilégios de acesso do usuário, ou algum outro item necessário para lidar com um erro, então você emitir uma instrução throw com o objeto de exceção apropriado. O nível anterior do aplicativo receberá a exceção e determinar se ele pode lidar com isso.

No entanto, se o método main () recebe a exceção, em seguida, você deve determinar o que fazer com o erro ou o aplicativo irá falhar. É geralmente considerado má prática de programação simplesmente deixar o travamento de aplicação - você precisa vir para cima com alguma forma de lidar com os erros que os encontros de aplicação.

tratamento de erros necessária

Java fornece dois tipos de excepções: verificados (aqueles monitorados pelo JRE) e sem controle (aqueles que não são monitorados pelo JRE). Você tem a opção de lidar com uma exceção não verificada. No entanto, Java obriga a pessoa a lidar com uma exceção verificada. Seu código não vai mesmo compilar se você tentar usar um método que tem uma exceção verificada associado a ele.

A exceção verificada é aquele que o JRE é contada por a definição de classe para monitorar. O JRE força o usuário da classe para fornecer tratamento para a exceção para garantir que a classe realiza de forma confiável.

Todos os tipos de detalhes estranhos estão associados com exceções verificadas e não verificadas. Uma maneira fácil de saber se uma exceção é verificada é conhecer a classe pai. Todas as exceções que são uma subclasse das classes de erro ou RuntimeException estão desmarcadas - cada outra exceção é verificada.

A melhor prática é para lidar com todas as exceções na sua aplicação, e você não terá que se preocupar se uma exceção está marcada ou desmarcada. Um grande desenvolvedor sempre lida com possíveis erros - que é a linha de fundo.