Este artigo se concentra em alguns conceitos de mecanismo de exceção em Java. O objetivo de escrever este artigo é me facilitar para lembrar essas coisas depois de muito tempo.
1. Mecanismo de exceção
1.1 O mecanismo de exceção refere -se a como o programa lida quando ocorre um erro. Especificamente, o mecanismo de exceção fornece um canal seguro para saída do programa. Quando ocorre um erro, o processo de execução do programa muda e o controle do programa é transferido para o processador de exceção.
1.2 A maneira tradicional de lidar com exceções é que a função retorna um resultado especial para indicar que ocorre uma exceção (geralmente esse resultado especial é comumente conhecido como é), e o programa chamando a função é responsável por verificar e analisar os resultados retornados pela função. Isso tem as seguintes desvantagens: por exemplo, se a função retornar -1, significa que ocorre uma exceção, mas se a função quiser retornar o valor correto de -1, será confundido; A legibilidade é reduzida e o código do programa é misturado com o código que lida com a exceção; O programa chamando a função analisa o erro, que exige que o programador do cliente tenha um profundo entendimento das funções da biblioteca.
1.3 Processo de manuseio de exceção
1.3.1 Quando um erro é encontrado, o método termina imediatamente e não retorna um valor; Ao mesmo tempo, um objeto de exceção é jogado.
1.3.2 O programa que chama esse método não continuará sendo executado, mas procura um manipulador de exceção que possa lidar com a exceção e executa o código nele.
2 Classificação de exceções
2.1 Classificação de exceções
2.1.1 A estrutura de herança das exceções: a classe base é lançada, erro e exceção Heritable Throwable, RunTimeException e IoException, etc., e a tempo de execução específica herda o tempo de execução.
2.1.2 Erro e tempo de execução O Exception e suas subclasses se tornam exceções desmarcadas, e outras exceções se tornam exceções verificadas.
2.2 Características de cada tipo de exceção
2.2.1 Sistema de erro O sistema de classe de erro descreve erros internos e exaustão de recursos no sistema operacional Java. Os aplicativos não devem lançar objetos desse tipo (geralmente jogados por máquinas virtuais). Se esse erro ocorrer, não há mais nada que possa ser feito, exceto para tentar fazer o programa sair com segurança. Portanto, ao projetar programação, você deve prestar mais atenção ao sistema de exceção.
2.2.2 Sistema de exceção Sistema de exceção Inclui o sistema RunTimeException e outros sistemas não-RuntimeException
2.2.2.1 RuntimeTexception O sistema RuntimeException inclui conversão do tipo errado, acesso fora dos limites, tentativas de acessar ponteiros nulos, etc. O princípio de lidar com o tempo de execução é: Se ocorrer uma tempo de execução, deve ser um erro de um programador. Por exemplo, as exceções de acesso à matriz fora dos limites podem ser evitadas por verificando os subscritos da matriz e os limites da matriz.
2.2.2.2 OUTRAS (ioException, etc.) Exceções como essa geralmente são erros externos, como tentar ler dados do final do arquivo, etc. Isso não é um erro do próprio programa, mas um erro externo que ocorre no ambiente do aplicativo.
2.3 Diferenças da classificação de exceção C ++
2.3.1 De fato, o nome da classe de RuntimeException em Java não é apropriado, porque qualquer exceção ocorre em tempo de execução. (Os erros que ocorrem durante a compilação não são exceções. Em outras palavras, as exceções são resolver erros que ocorrem durante a execução do programa).
2.3.2 Logic_error em C ++ é equivalente à RunTimeException em Java, enquanto Runtime_error é equivalente a exceções dos tipos de não ruptura de RuntimeException em Java.
3. Como usar exceções
3.1 Declarar Método lança exceção
3.1.1 Sintaxe: lances (omitidos)
3.1.2 Por que precisamos declarar um método para lançar uma exceção? Se um método lança uma exceção é tão importante quanto o tipo de valor de retorno do método. Supondo que o método ligue uma exceção, ele não declare que o método lançará uma exceção, o programador do cliente pode chamar esse método sem escrever código para lidar com a exceção. Então, uma vez que ocorre uma exceção, não existe um controlador de exceção adequado para resolver essa exceção.
3.1.3 Por que a exceção lançada é necessariamente uma exceção verificada? RunTimeException e erro podem ser gerados em qualquer código. Eles não precisam ser jogados pelo programador. Depois que ocorre um erro, a exceção correspondente será lançada automaticamente. A exceção verificada é lançada pelo programador, que é dividido em duas situações: o programador do cliente chama a função da biblioteca que lança a exceção (a exceção da função da biblioteca é lançada pelo programador da biblioteca); O programador do cliente lança a exceção por si mesmo usando a declaração de arremesso. Ao encontrar um erro, os programadores geralmente são impotentes; Ao encontrar uma hora de execução, deve ser que exista um erro lógico no programa e o programa precisa ser modificado (equivalente a um método de depuração); Somente a exceção verificada é o que os programadores se preocupam e o programa deve e deve jogar ou lidar apenas com a exceção verificada.
3.1.4 Nota: O método da subclasse que abrange um determinado método da classe pai não pode lançar mais exceções do que o método da classe pai. Portanto, às vezes, ao projetar o método da classe pai, as exceções serão declaradas arremessadas, mas o código real para implementar o método não lançará exceções. O objetivo disso é facilitar o método da subclasse para substituir o método da classe pai.
3.2 Como jogar uma exceção
3.2.1 Sintaxe: arremesso (omitido)
3.2.2 Que exceção é lançada? Para um objeto de exceção, o tipo de objeto é realmente útil quando a exceção é do tipo de objeto, e o próprio objeto de exceção não tem sentido. Por exemplo, se o tipo de objeto de exceção for ClassCastException, esse nome de classe é a única informação útil. Portanto, ao escolher qual exceção a ser lançada, o mais importante é selecionar o nome da classe da exceção que pode explicar claramente a situação de exceção.
3.2.3 Geralmente, existem dois construtores para objetos de exceção: um é um construtor sem parâmetros; O outro é um construtor com uma string, que será usada como uma descrição adicional para este objeto de exceção, além do nome do tipo.
3.2.4 Crie sua própria exceção: quando nenhuma das exceções internas do Java não pode explicar claramente a situação de exceção, você precisa criar sua própria exceção. Deve -se notar que a única coisa útil é a informação do nome do tipo, portanto, não gaste energia no design de classes de exceção.
3.3 Capture exceções Se uma exceção não for processada, para um programa de interface não gráfico, o programa será abortado e a saída de informações de exceção; Para um programa de interface gráfica, as informações de exceção também serão emitidas, mas o programa não abortará, mas retorna ao loop de processamento de interface do usuário.
3.3.1 Sintaxe: a tentativa, a captura e, finalmente (omitida), os módulos do controlador devem estar imediatamente atrás do bloco de tentativa. Se uma exceção for lançada, o mecanismo de controle de exceção procurará o primeiro controlador cujos parâmetros correspondem ao tipo de exceção e depois entrarão na cláusula de captura e pensarão que a exceção foi controlada. A busca pelo controlador também parará assim que a cláusula de captura for concluída.
3.3.1.1 Pegue várias exceções (observe a sintaxe e a ordem de captura) (omitida)
3.3.1.2 Processo de uso e manuseio de exceção de finalmente (omitido)
3.3.2 O que o manuseio de exceções faz? Para Java, devido à coleta de lixo, o manuseio de exceções não requer reciclagem de memória. No entanto, ainda existem alguns recursos que os programadores precisam coletar, como arquivos, conexões de rede e imagens.
3.3.3 O método deve lançar uma exceção ou pegar uma exceção no método? Princípio: capturar e lidar com exceções que sabem como lidar e passar exceções que não sabem como lidar
3.3.4 Jogue uma exceção novamente
3.3.4.1 Por que faço uma exceção novamente? Nesse nível, apenas parte do conteúdo pode ser processada e algum processamento precisa ser concluído em um ambiente de nível superior; portanto, uma exceção deve ser lançada novamente. Isso permite que cada estágio do manipulador de exceção lide com exceções que ele pode suportar.
3.3.4.2 O bloco de captura correspondente ao mesmo bloco de tentativa será ignorado e a exceção jogada entrará em um nível mais alto.
4 outras perguntas sobre exceções
4.1 Exceção excessiva de uso em primeiro lugar, é muito conveniente usar exceções; portanto, os programadores geralmente não estão mais dispostos a escrever códigos para lidar com erros, mas simplesmente lançam uma exceção. Isso está errado. Para erros completamente conhecidos, o código que lida com esses erros deve ser gravado para aumentar a robustez do programa. Além disso, a eficiência do mecanismo anormal é muito ruim.
4.2 Dividir exceções de erros comuns. Para erros comuns, os códigos que lidam com esses erros devem ser gravados para aumentar a robustez do programa. Exceções são necessárias apenas para erros de tempo de execução indetermináveis e previstos externos.
4.3 Informações contidas em objetos de exceção em geral, as únicas informações úteis para objetos de exceção são informações de tipo. Mas ao usar um construtor de string de exceção, essa string também pode ser usada como informações adicionais. Chamando os métodos getMessage (), ToString () ou PrintStackTrace () do objeto de exceção podem obter informações adicionais, nome de classe e informações da pilha de chamadas, respectivamente. E o último contém informações que são um superconjunto do primeiro.
Exceções comumente usadas:
Operações não suportadas pela UnsupportEdOperationException
Parâmetros ilegais de órgãos ilegais
IndexOutOfBoundSexception Índice de saída
IllegalStateException Estado ilegal
Existe uma certa diferença entre avisos anormais e comuns. Quando ocorre uma exceção no aplicativo, o fluxo normal de instrução do programa de execução será interrompido. Ou seja, o código após uma exceção ocorrer não será executado corretamente. Até aciona a operação de reversão do banco de dados.
Na plataforma de desenvolvimento Java, exceções incluem exceções predefinidas e exceções personalizadas. Esses dois tipos de exceção se complementam. Como desenvolvedor de programas qualificado, seja bom em usar exceções em aplicativos. Isso pode melhorar a interatividade do aplicativo. Ao mesmo tempo, também é um pré -requisito para garantir a operação normal do aplicativo. Portanto, o manuseio de exceção é muito importante para o desenvolvimento de uma excelente aplicação. Por esse motivo, o autor acredita que os desenvolvedores do programa devem ter um entendimento profundo das exceções comuns nos aplicativos Java. Somente quando você entende essas exceções comuns, você pode lidar bem com exceções personalizadas.
1. Tipos e causas de exceções comuns.
Em relação às exceções comuns nos aplicativos Java, o autor acredita que os desenvolvedores do programa devem entendê -los de dois aspectos. Primeiro, precisamos saber quais são as exceções de aplicativo Java comum e, segundo, precisamos saber quais causas podem causar essa exceção. Isso não apenas exige que os gerentes do programa prestem atenção à acumulação em seu trabalho diário, mas também precisa coletar informações de outros canais, se necessário. O autor conduzirá uma análise sobre isso, esperando que ajude a todos os desenvolvedores do programa.
1. SQLEXCECCIONE: Opere a classe de exceção do banco de dados.
A maioria dos aplicativos Java de hoje depende de bancos de dados para executar. Esta classe será acionada se ocorrer um erro quando um aplicativo Java se comunicar com o banco de dados. Ao mesmo tempo, as informações de erro do banco de dados serão exibidas ao usuário através desta classe. Em outras palavras, esta classe de exceção de banco de dados operacional é uma ponte para a transmissão de informações de exceção entre o banco de dados e o usuário. Por exemplo, o usuário agora insere dados no sistema e estipula que um determinado campo deve ser exclusivo no banco de dados. Quando o usuário insere dados, se o valor desse campo for repetido com o registro existente, ele viola as restrições de singularidade do banco de dados e uma mensagem de exceção será lançada no banco de dados. Essas informações podem não ser visíveis para os usuários, pois ocorre no nível do banco de dados. No momento, esta classe de exceção do banco de dados de operação capturará as informações de exceção do banco de dados e passará as informações de exceção ao primeiro plano. Dessa forma, o usuário da recepção pode analisar a causa do erro com base nessas informações de exceção. Esse é o principal objetivo desta classe de exceção de banco de dados operacional. Nos aplicativos Java, esta classe será acionada quando todas as operações de banco de dados ocorrerem exceções. Todas as informações rápidas do próprio aplicativo Java geralmente são gerais demais no momento, apenas dizendo que há um erro na interação com o banco de dados e não possui muito valor de referência. No momento, as informações de prompt de banco de dados são mais valiosas.
2. ClassCastException: Exceção de conversão do tipo de dados.
Nos aplicativos Java, às vezes o tipo de dados precisa ser convertido. Essa conversão inclui conversões exibidas e conversões implícitas. No entanto, não importa como você converta, você deve atender a um pré -requisito, a saber, a compatibilidade dos tipos de dados. Se esse princípio for violado durante o processo de conversão de dados, a exceção de conversão do tipo de dados será acionada. Por exemplo, nos aplicativos agora, os desenvolvedores precisam converter dados de data do tipo de caractere em dados do tipo Date-Type que podem ser aceitos pelo banco de dados. Nesse momento, eles só precisam controlá -lo em primeiro plano, e geralmente não haverá problemas. No entanto, se o aplicativo em primeiro plano não tiver controle relevante, como o usuário insere apenas as informações do mês e do dia ao entrar na data, mas não possui as informações do ano. No momento, uma exceção aparecerá quando o aplicativo executar a conversão do tipo de dados. De acordo com a minha experiência, as exceções de conversão do tipo de dados fazem com que mais exceções ocorram no desenvolvimento de aplicativos e também são exceções de nível relativamente baixo. Porque, na maioria dos casos, alguns tipos de controle forçados sobre dados podem ser executados na janela do aplicativo. Ou seja, antes que o tipo de dados seja convertido, a compatibilidade do tipo de dados é garantida. Nesse caso, não será fácil causar exceções de conversão do tipo de dados. Se em campos que permitirem apenas tipos numéricos, será possível definir caracteres que não sejam valores numéricos que não podem entrar. Embora com o mecanismo de manuseio de exceção, o aplicativo não será executado incorretamente. No entanto, no desenvolvimento real, ainda devemos prever o máximo possível as causas dos erros e tentar evitar anormalidades.
3. NumberFormatexception: Exceção arremessada quando uma string é convertida em um tipo numérico.
Durante o processo de conversão do tipo de dados, se for um problema que ocorre durante o processo de conversão de caracteres em conversão numérica, uma exceção independente é usada no programa Java, como NumberFormatexception. Por exemplo, quando os dados do tipo de caractere "123456" são convertidos em dados numéricos, são permitidos. No entanto, se os dados do tipo de caractere contiver caracteres não numéricos, como 123#56, uma exceção aparecerá quando convertida em tipo numérico. O sistema pegará essa exceção e o processará.
Existem muitas classes de exceção comuns em aplicativos Java. Se a exceção de classe correspondente não for encontrada, algumas exceções de classe não poderão ser acessadas, o arquivo terminou a exceção, o arquivo não encontrou exceção, o campo não encontrou exceção, etc. Geralmente, os desenvolvedores do sistema podem julgar o tipo de exceção atual com base nesse nome de exceção. Embora seja bom, uma boa memória não é tão boa quanto uma caneta ruim. Quando necessário (especialmente quando há uma exceção personalizada), o desenvolvedor do programa finalmente tem uma lista de exceções em mãos. Nesse caso, se o aplicativo descobre um problema durante a depuração ou recebe uma reclamação do usuário durante a operação, você pode encontrar a causa da exceção com base no nome da exceção no tempo. Isso permite que exceções sejam resolvidas no menor tempo e restaura a operação normal do aplicativo. Essa medida tem sido usada há muitos anos e é muito eficaz.
2. Sugestões práticas para gerenciamento de exceções.
Para exceções de banco de dados operacionais, os aplicativos Java fornece apenas uma classe de exceção. Portanto, confiar apenas nas informações de erro dos aplicativos Java geralmente não podem ajudar o pessoal do aplicativo a eliminar as causas do erro. Você pode especificar apenas se essa exceção é causada por um erro de aplicativo ou um erro de banco de dados. Para especificar ainda mais a causa do problema, é melhor explicar a causa específica ao definir exceções no nível do banco de dados. Por exemplo, o aplicativo em primeiro plano pode chamar as funções ou procedimentos do banco de dados. No momento, fazer um bom trabalho na função ou processo do banco de dados pode explicar a causa específica de uma certa exceção. Por exemplo, ao gerar outra tabela com base em uma certa tabela básica, um determinado campo não pode estar vazio, etc. Depois de explicar essas informações de exceção claramente, se você realmente encontrar exceções semelhantes, operar a classe de exceção do banco de dados reverterá as informações de exceção do banco de dados ao usuário do front-end. Isso ajudará os usuários a encontrar a causa do problema e a corrigi -lo no menor tempo. Obviamente, isso requer coordenação entre programadores Java e designers de banco de dados.
Em segundo lugar, deve -se notar que as exceções não são a norma. Em outras palavras, a maioria das anormalidades pode ser eliminada por meio de previsão e prevenção razoável da premissa. Se projetado para operações de quatro pontos, você pode restringir os valores de entrada 0 no campo Ex-Number na janela do aplicativo em primeiro plano para eliminar possíveis exceções durante a operação de aplicação. No entanto, isso geralmente exige que os desenvolvedores de aplicativos tenham rica experiência de trabalho e tenham lógica estrita de pensamento. Embora isso seja difícil, o autor acredita que os desenvolvedores do programa ainda devem trabalhar duro nesse sentido, em vez de sempre deixar os usuários como seus depoimentos para permitir que os usuários descubram o design de bugs no aplicativo. O autor acredita que as exceções podem ser jogadas apenas quando alguns fatores que estão realmente fora do controle dos programadores. Se os desenvolvedores de aplicativos puderem estar cientes desse erro, mas ainda não prestam atenção ou tomar medidas efetivas para evitar essa anormalidade, o autor não o permitirá.
ArithmeticException (Exception with divisor 0), BufferOverflowException (Buffer overflow exception), BufferUnderflowException (Buffer underflow exception), IndexOutOfBoundsException (Outbounds exception), NullPointerException (NullPointerException), EmptyStackException (Empty Stack Exception), IllegalArgumentException (Illegal Parameter Exception), NegativeArraySizeException, NosuchElementException, SecurityException, SystemException, Unde -GarethrowableException
1. Java.lang.NullPointerException
A explicação da exceção é "o programa encontra um ponteiro nulo". Simplificando, significa chamar um objeto não inicializado ou um objeto que não existe, ou seja, confundindo a inicialização da matriz com a inicialização dos elementos da matriz. A inicialização de uma matriz é alocar o espaço necessário para a matriz. Os elementos da matriz inicializada não são instanciados e ainda estão vazios; portanto, cada elemento precisa ser inicializado (se você quiser chamá -lo)
2. Java.lang.classnotfoundException
A explicação da exceção é "a classe especificada não existe".
3. Java.lang.arithmeticexception
A explicação dessa exceção é "Exceção de operação matemática". Por exemplo, se uma operação como a divisão por zero aparecer em um programa, essa exceção ocorrerá.
4
A explicação da exceção é "os subscritos de matriz estão fora dos limites". A maioria dos programas agora tem operações em matrizes. Portanto, ao ligar para as matrizes, você deve verificar cuidadosamente se os subscritos que você chama excedem o intervalo da matriz. De um modo geral, não é fácil cometer esses erros chamando o Display (ou seja, usando diretamente as chamadas de constantes para o subscrito), mas implícito (ou seja, usando variáveis para representar subscritos) geralmente cometem erros. Há outra situação em que a duração da matriz definida no programa é determinada por certos métodos específicos e não é declarada antecipadamente. Neste momento, é melhor verificar primeiro a duração da matriz para evitar essa exceção.
5. java.lang.illegalargumentException
A explicação dessa exceção é "o erro do parâmetro do método", como os três valores no método G.setColor (int vermelho, int verde, int azul). Se houver mais de 255, essa exceção também ocorrerá. Portanto, uma vez encontrado essa exceção, o que precisamos fazer é verificar rapidamente se há um erro no parâmetro que passa na chamada do método.
6. java.lang.illegalaccessception
A explicação dessa exceção é "sem permissão de acesso". Essa exceção ocorrerá quando o aplicativo quiser ligar para uma classe, mas o método atual não possui permissões de acesso à classe. Ao usar o pacote no programa, você deve prestar atenção a esta exceção, exceção e java
Obrigado pela leitura, espero que isso possa ajudá -lo. Obrigado pelo seu apoio a este site!