Eu li no tutorial do Java SE que não é recomendável tratar exceptions do tipo Error ou RuntimeException, apenas classes herdeiras da classe Exception. Porém, RuntimeException é herdeira de Exception, se eu tratar um Exception estarei tratando também RuntimeException?
Por exemplo:
try
{
}
catch (Exception e)
{
}
Neste caso meu catch vai pegar RuntimeException também?
assim qualquer excessao que ocorrer ele tratará se vc usar o Exception, tente usar excessoes definidas, tp se quiser tratar excessoes sql use SQLException, e assim por diante…
Sim, vai pegar todas as exceções.
Pense em um “catch” como sendo um filtro ou uma peneira. Uma peneira com o maior furo possível usa “catch (Throwable ex)”, já que java.lang.Throwable é a superclasse de java.lang.Exception, e de java.lang.Error. Por sua vez, java.lang.Exception é a superclasse de java.lang.RuntimeException e também de N outras exceções - por exemplo,
AnnotationTypeMismatchException, ArithmeticException, ArrayStoreException, BufferOverflowException, BufferUnderflowException, CannotRedoException, CannotUndoException, ClassCastException, CMMException, ConcurrentModificationException, DataBindingException, DOMException, EmptyStackException, EnumConstantNotPresentException, EventException, IllegalArgumentException, IllegalMonitorStateException, IllegalPathStateException, IllegalStateException, ImagingOpException, IncompleteAnnotationException, IndexOutOfBoundsException, JMRuntimeException, LSException, MalformedParameterizedTypeException, MirroredTypeException, MirroredTypesException, MissingResourceException, NegativeArraySizeException, NoSuchElementException, NoSuchMechanismException, NullPointerException, ProfileDataException, ProviderException, RasterFormatException, RejectedExecutionException, SecurityException, SystemException, TypeConstraintException, TypeNotPresentException, UndeclaredThrowableException, UnknownAnnotationValueException, UnknownElementException, UnknownTypeException, UnmodifiableSetException, UnsupportedOperationException, WebServiceException
No Java é necessário pôr os furos menores (ou seja, as subclasses) antes dos furos maiores (estranho, não? Mas é assim mesmo).
Na verdade o recomendado é não tratar Error, já que estes quando ocorrem geralmente não tem o que fazer.
Exception são exceções previstas, que podem sempre ocorrer, e que quem criou o método esta avisando a que esta usando, para checar as exceções
Exceção não é um erro, é simplismente algo que não segue o fluxo normal das coisas, mais que pode ser contornado.
RuntimeException são exceções que normalmente podem ocorrer em tempo de execução, por isso não são necessariamente testadas em todo escopo, estas exceções devem receber o tratamento em sua origem…
Ps.: Apesar de RuntimeException ser sub-classe de Exception, vc não precisa de try{}catch(){} ao usar um método que gere esse tipo de exceção,
mais pode usar, caso queira tratar a exceção.
…
Para ficar um pouquinho + claro, NullPointerException … exceção gerado quando um objeto nulo é enviado a um escopo que não consegue realizar a tarefa quando este objeto é nulo…
Maioria dos métodos não testam a toda hora c a variavel é nula, principalmente quando isso não é esperado, por isso entede que quem esta usando, sabe que ele pode lançar essa exceção em Runtime, por isso não precisa declarar Try{}catch(){} … porem vc pode faze-lo …
Onde é o lugar de tratar esse tipo de exceção ?? geralmente na origem do problema…
digamos que vc recupere esse dado de uma interface, na hora q vc recuperar o dado, vc checa, e c for nulo, vc não tenta executar o método pois vai dar problema… e retorna uma msg do tipo, o campo X não pode ser nulo…
…
uma Exception é algo que foi pedido que vc trate… por exemplo, quando vc pede pra ler um Arquivo, pode ser que o arquivo não exista, ou que vc tenha escrito um nome de arquivo invalido, ou que vc não tenha acesso, etc etc… quando esses problemas ocorrem não da pra abrir o arquivo… neste caso, os métodos de abrir arquivo, pedem explicitamente para checar as exceções, e neste caso vc deve tratalas ^^
espero que de pra entender
Entendi o que vocês me explicaram. Agora tenho outra dúvida relacionada: estou criando um sistema J2EE com EJB que roda no Glassfish, pretendo fazer todo o tratamento das Exceptions e exibir mensagens ou perguntas ao usuário dependendo do Exception. Porém, quando ocorrer um Error ou RuntimeException, não vou tratá-los, como foi recomendado, mas gostaria de ter um controle sobre esses erros, pois podem ser erro no sistema em determinadas ocasiões. Pretendo fazer um mecanismo que me envie e-mails com estes tipos de erros ocorridos nos clientes, assim como faço no meu sistema atual em Delphi.
Mas como eu faria para capturar exceções do tipo Error e RuntimeError de maneira genérica, isto é, em qualquer lugar onde ocorrerem, de modo que seja disparado um evento meu para poder fazer o envio do e-mail?
No Delphi existe um evento para isto.
Erro não precisa tratar… RuntimeException precisa sim ^^
va por mim, a diferença é que RuntimeException, não precisa ser tratado diretamente por quem chama um método…
um exemplo de RuntimeException, é vc fazer um parse de um String em um Integer… imagine c vc tiver um campo, onde vc fale pro usuario digitar um número, e o usuario vai la e digita “0.2-14,76” … vai gerar um exceção na hora de passar de String pra Integer, a não ser que vc trate a exceção…
Uma das formas de tratar é transformar a String em algo apenas númerico usando string.replaceAll( “\D*”, “” ); outra forma é vc falando pro usuario que aquele valor não é aceito, porem esse tipo de coisa tem que ser tratada…
mais c vc decidir não tratar… toda vez quem alguem na interface não digitar números o sistema vai gerar uma java.lang.NumberFormatException
…
O normal é
Error - nunca tratar (mas fazer o log)
Exception - tratar sempre, de preferencia por quem invoca o método.
RuntimeException - tratar na origime do erro, e não exatamente aonde vc estiver invocando o método
mais Exception precisa de tratamento, mesmo que seja uma Runtime, e um modo de tratar uma Runtime é garantindo com que ela nunca ocorra, essa é a diferença não precisa Try{}catch{} basta que vc garanta que a Runtime nunca venha a ocorrer.
…
Mas respondendo a sua pergunta, não sei bem fazer o esquema de loggin não
Para receber e-mails eu não sei como faz, mas para fazer logs existe a classe Logger no pacote java.util.logging (bem completo, porém um pouco complexo. É por isso que existem outras alternativas: http://paste.la/61704).
tem uma api pra mandar email
procure por JavaMail
[quote=Lavieri]Erro não precisa tratar… RuntimeException precisa sim ^^
va por mim, a diferença é que RuntimeException, não precisa ser tratado diretamente por quem chama um método…
um exemplo de RuntimeException, é vc fazer um parse de um String em um Integer… imagine c vc tiver um campo, onde vc fale pro usuario digitar um número, e o usuario vai la e digita “0.2-14,76” … vai gerar um exceção na hora de passar de String pra Integer, a não ser que vc trate a exceção…
Uma das formas de tratar é transformar a String em algo apenas númerico usando string.replaceAll( “\D*”, “” ); outra forma é vc falando pro usuario que aquele valor não é aceito, porem esse tipo de coisa tem que ser tratada…
mais c vc decidir não tratar… toda vez quem alguem na interface não digitar números o sistema vai gerar uma java.lang.NumberFormatException
…
O normal é
Error - nunca tratar (mas fazer o log)
Exception - tratar sempre, de preferencia por quem invoca o método.
RuntimeException - tratar na origime do erro, e não exatamente aonde vc estiver invocando o método
mais Exception precisa de tratamento, mesmo que seja uma Runtime, e um modo de tratar uma Runtime é garantindo com que ela nunca ocorra, essa é a diferença não precisa Try{}catch{} basta que vc garanta que a Runtime nunca venha a ocorrer.
…
Mas respondendo a sua pergunta, não sei bem fazer o esquema de loggin não[/quote]
Obrigado. Vou seguir suas sugestões.
[quote=marcosharbs]tem uma api pra mandar email
procure por JavaMail[/quote]
Quanto a isso não tem problema, minha dúvida é se existe algum evento que posso tratar para capturar erros que não foram tratados em nenhum lugar do sistema, ou melhor, algo que seja chamado antes do sistema finalizar devido a um erro não tratado.