Checked e Unchecked Expection

4 de maio de 2012 16 respostas

macario1983 4 de maio de 2012

Bom dia moçada tudo bem?

Estou com dificuldades em entender sobre checked e unchecked exception pois estou estudando java basico e ai eu ja consegui tratar excessoes neste estilo aqui ó

package exception;

import java.util.Scanner;

public class Principal {
	
	/*
	 * essa classe é o metodo principal
	 * nela pego os 2 valores int
	 * e chamo metodo divide da classe Divide
	 */

	public static void main(String[] args) throws Excessao {

		Scanner input = new Scanner(System.in);

		int num1 = input.nextInt();
		int num2 = input.nextInt();

		Divide.divide(num1, num2);

	}
}

class Divide {
	
	/*
	 * esta classe é para realizar a divisão
	 * fiz um metodo aonde entra com 2 valores e o metodo faz verificacao
	 * se o denominador que é o b for igual a zero lança excessao
	 * se nao imprime na tela o valor da divisao de inteiros
	 */

	public static void divide(int a, int b) throws Excessao { //digo que existe essa excessao para a classe

		try {
			if (b == 0) {
				throw new Excessao(); //lanço a classse excessao
			}
			System.out.println((a / b));

		} catch (Excessao e) {
			System.out.println(e.getMessage()); //jogo na tela a mensagem de erro da classe
		}
	}

}

class Excessao extends Exception {

	/*
	 * criei a classe excessao
	 * efetuei sobrecarga no metodo getmessage atraves da palavra @Override
	 * criei uma string mensagem constante e somente visiavel a classe
	 */
	
	private final String mensagem = "Divisão de numeros inválida";

	@Override
	public String getMessage() {
		return mensagem;
	}

}

Este codigo acima criei so pra ajudar uns amigos de classe a entenderem melhor

Mas voltando a checked e unchecked exception so que uma deriva de runtimeexception e a outra de exception…

Alguem poderia me ajudar a compreender por favor…

Valeu

16 Respostas

nel 4 de mai. de 2012

Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

denisspitfire 4 de mai. de 2012

nel:
Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

E quando pedimos throw? uso tanto try e catch como o throw diversas vezes mas nunca 100% de certeza do que estou fazendo. Vou dar uma pesquisada melhor no assunto para achar melhores definições, estou pensando em fazer o curso online da Caelum para melhorar a O.O

nel 4 de mai. de 2012

Tem o artigo do Sergio Taborda, sobre exceções: http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/trabalhando-com-excecoes-conceitos/ Acho excelente. Vale a pena você ler.

nel 4 de mai. de 2012

denisspitfire:
nel:
Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

E quando pedimos throw? uso tanto try e catch como o throw diversas vezes mas nunca 100% de certeza do que estou fazendo. Vou dar uma pesquisada melhor no assunto para achar melhores definições, estou pensando em fazer o curso online da Caelum para melhorar a O.O

O throw vai gerar uma exceção tratável, pois qualquer objeto que use aquela referência, seja no construtor ou no método, será obrigado ou a lançar a exceção para a frente (throws…) ou usar um try-catch para tratar essa exceção.

macario1983 4 de mai. de 2012

nel:
Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

Eu me lembro que em um dos materiais que li chegavam a tratar a diferença entre erros de execucao e logica, nos quais os de logica o programador deveria tratar…

Agora erro de execução com nullpointerException ja seria complicado

macario1983 4 de mai. de 2012

denisspitfire:
nel:
Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

E quando pedimos throw? uso tanto try e catch como o throw diversas vezes mas nunca 100% de certeza do que estou fazendo. Vou dar uma pesquisada melhor no assunto para achar melhores definições, estou pensando em fazer o curso online da Caelum para melhorar a O.O

Cara eu to começando mas se eu estiver errado podem me corrijir ate para eu aprender

Mas o throw vc para naquele momento a execução do codigo…lançando aquele excessao…

O throws vc diz ao metodo que existe aquelas classes de excessoes e elas podem ser lançadas caso existão…

O bloco try catch seria assim

no try vc tenta executar a o codigo normal caso de excessão ele cai pra dentro do catch

nel 4 de mai. de 2012

macario1983:
nel:
Você não consegue prever uma RunTimeException, pelo simples motivo de ela ocorrer em tempo de execução (runtime…). Mas a Exception já é um tipo de exceção “prevista”, que pode vir a ocorrer. Um exemplo disso é na leitura de arquivos, o próprio compilador já pede um try-catch para a IOException.

As RunTimeException ocorrem quando você não conseguiu prever em código uma determinada exceção. Essa é a idéia.

Eu me lembro que em um dos materiais que li chegavam a tratar a diferença entre erros de execucao e logica, nos quais os de logica o programador deveria tratar…

Agora erro de execução com nullpointerException ja seria complicado

Pois é. NullPointerException ocorre em Runtime. Algumas IDE´s até avisam, com warning, que você está usando uma referência nula. Mas e quem não usa esse tipo de IDE ?

Você não vai me colocar um try-catch para NullPointerException né? Mas enfim, a ideia é essa.

Rodrigo_Sasaki 4 de mai. de 2012

vale lembrar que usar try/catch e throws pra mesma exceção no mesmo método não é nada prático.

porque imagine o caso:

public void metodo() throws FileNotFoundException{ File f = new File("C:\\"); try{ FileReader fr = new FileReader(f); } catch (FileNotFoundException e){ //Trata a exception aqui } }

se for lançada a FileNotFoundException, ela será tratada no bloco try/catch, e não será “lançada para fora” que é o que indica o throws.

Portanto acho importante definir isso caso a caso, ou um, ou outro.

macario1983 4 de mai. de 2012

digaoneves:
vale lembrar que usar try/catch e throws pra mesma exceção no mesmo método não é nada prático.

porque imagine o caso:

public void metodo() throws FileNotFoundException{ File f = new File("C:\\"); try{ FileReader fr = new FileReader(f); } catch (FileNotFoundException e){ //Trata a exception aqui } }

se for lançada a FileNotFoundException, ela será tratada no bloco try/catch, e não será “lançada para fora” que é o que indica o throws.

Portanto acho importante definir isso caso a caso, ou um, ou outro.

Não entendi muito bem…

Pensava que chamava o throws na assinatura do metodo para indicar que aquele metodo pode gerar aquele tipo de excessao…

denisspitfire 4 de mai. de 2012

mas nao é para usar os dois metodos de “tratamento” ao mesmo tempo… ou try e catch ou throws

Rodrigo_Sasaki 4 de mai. de 2012

macario1983:
Não entendi muito bem...
Pensava que chamava o throws na assinatura do metodo para indicar que aquele metodo pode gerar aquele tipo de excessao...

Você está certo.. você avisa o "chamador" do seu método que este método chamado pode lançar um certo tipo de exceção, e cabe ao "chamador" tratar da melhor maneira, mas se a exceção ja é tratada dentro do método chamado, não é necessário avisar ninguém, fez sentido?

public callerMethod(){
    try{
        methodWithThrows();
    }catch(FileNotFoundException e){
        System.out.println("Ops, não encontrei seu arquivo!");
    }
    methodWithTryCatch();
}

public methodWithThrows() throws FileNotFoundException{
   //Aqui dentro não há try/catch portanto é necessário que o callerMethod() a trate da melhor maneira
}

public methodWithTryCatch(){
    try{
        //implementacao
    }catch(FileNotFoundException e){
        System.out.println("Não encontrei o arquivo mas eu mesmo estou tratando o erro.");
    }
}

nel 4 de mai. de 2012

A mesma exceção não faz sentido, o comum é que se crie sua própria exceção, use o try-catch e depois lance a sua exceção.
Dessa forma, consegue controlar melhor o que está ocorrendo em seu sistema. Aqui mesmo, temos algumas…

macario1983 4 de mai. de 2012

pra fala a verdade fiquei mais confuso

pq tipo vc tenta tratar excessoes nais quais vc sabe que seu codigo pode gerar…

e para elas vc cria uma classe e informa com uma mensagem o aviso ao usuario do que esta sendo executado…

vc diz ao metodo que se pode lançar determinadas excessões mas vc precisa fazer um throw dela nao? afinal se vc tiver uma try catch aninhado vc precisa corresponder cada bloco a si

a não se que pelo entendi, quando é uma excessao na qual o java ja trata como arithimeticexception na qual eu posso apenas passar um mensagem mais amigavel ao usuario…

Rodrigo_Sasaki 4 de mai. de 2012

Você entendeu o exemplo que eu passei acima?

o que o nel quis dizer, é que você pode encapsular as exceções para saber melhor aonde estão sendo lançadas.
Imagine que você tem uma camada Business do seu projeto, e la tem seus BusinessObjects

class BusinessObject{

    public metodo() throws BusinessException{
        try{
            File f = new File("C:\");
            FileReader fr = new FileReader(f);
        }catch(FileNotFoundException e){
            throw new BusinessException(e);
        }
    }
}

Entendeu como funciona? é lançada uma exceção qualquer, mas você encapsula ela para uma BusinessException, então se ver o erro no log, vai ter uma idéia melhor de onde o erro está acontecendo, e na tela pode tratar todas as BusinessExceptions do mesmo jeito se quiser.

macario1983 4 de mai. de 2012

digaoneves:
Você entendeu o exemplo que eu passei acima?
o que o nel quis dizer, é que você pode encapsular as exceções para saber melhor aonde estão sendo lançadas.
Imagine que você tem uma camada Business do seu projeto, e la tem seus BusinessObjects
class BusinessObject{

    public metodo() throws BusinessException{
        try{
            File f = new File("C:\");
            FileReader fr = new FileReader(f);
        }catch(FileNotFoundException e){
            throw new BusinessException(e);
        }
    }
}
Entendeu como funciona? é lançada uma exceção qualquer, mas você encapsula ela para uma BusinessException, então se ver o erro no log, vai ter uma idéia melhor de onde o erro está acontecendo, e na tela pode tratar todas as BusinessExceptions do mesmo jeito se quiser.

Acho que seria algo que talvez eu tenha lido num forum ou livro, que fica mais facil de se localizar aonde esta o erro pois as classes ficam separadas e vc saber aonde esta o problema...

Mas eu faço é isso

Crio um classe de excessao

Crio uma classe aonde fica o metodo e uso essa excessao nela

E ai uso o metodo da classe para ficar bem distribuido...

Como eu disse sou novo então ainda to aprendendo....

macario1983 4 de mai. de 2012

digaoneves:
vale lembrar que usar try/catch e throws pra mesma exceção no mesmo método não é nada prático.

porque imagine o caso:

public void metodo() throws FileNotFoundException{ File f = new File("C:\\"); try{ FileReader fr = new FileReader(f); } catch (FileNotFoundException e){ //Trata a exception aqui } }

se for lançada a FileNotFoundException, ela será tratada no bloco try/catch, e não será “lançada para fora” que é o que indica o throws.

Portanto acho importante definir isso caso a caso, ou um, ou outro.

deixa eu tentar entender, pra ver se é o que aconteceu comigo ontem

eu naquela classe de exemplo la em cima tentava tratar quando o denominador é zero…

mas tipo eu senti dificuldade quando o metodo foi setado para dar retorno do tipo int…ai ele dava um arithmeticexception e ai n fazia sentido eu criar uma classe so pra isso…e hj eu vi um exemplo tipo o meu aonde o cara somente trocava a msg para algo mais amigavel para o usuario…

seria isso?

Criado 4 de maio de 2012

Ultima resposta 4 de mai. de 2012

Respostas 16

Participantes 4

16 Respostas

Topicos relacionados