Exceptions... vai compilar?

Se não tiver nenhuma pegadinha sintática, sim.

A classe Teste2 usa o try…catch(Exception e) anti-pattern.

Ou a resposta é óbvia (vai compilar) ou eu não estou vendo a pegadinha.

Foi isso que eu pensei tb Srs.

Postei isso pq me deparei com isso no projeto em que estou trabalhadno.
Mas o compilador reclamou que a minha classe “Teste2” nao conhece as 2 Exceptions mostradas no exemplo. Tiver que importar elas.

:shock:

Alguem pode me explicar o pq disso?
Pq eu achei HORRIVEL ter que adicionar no meu caso de uso a lib do J2EE pra satisfazer o compilador. Nao queria que a minha classe tivesse conhecimento delas. Dai o “catch” mais amplo.

Fiquei meio confuso.

fabiocsi:

Alguem pode me explicar o pq disso? Pq eu achei HORRIVEL ter que adicionar no meu caso de uso a lib do J2EE pra satisfazer o compilador. Nao queria que a minha classe tivesse conhecimento delas. Dai o "catch" mais amplo.

Fiquei meio confuso.

package x;

public class BlaBla {
    public void metodoQualquer() throws ExceptionQualquer {
        // ...
    }
}

package y;

import x.BlaBla;

public class DaDaDa {
    public void outroMetodo() {
        BlaBla b = ...
        b.metodoQualquer(); // ***
    }
}

Na linha com *** O compilador vê o método metodoQualquer() e pela sua assinatura sabe que ele pode lançar a exceção. Como é uma exceção verificada, deve ser ou tratada ou relançada. Isso significa que ou você dá catch ou você da throws, e por isso DaDaDa teria que fazer isso.

Basicamente o throws de metodoQualquer diz "quem for usar esse método deve se preocupar com ExceptionQualquer". Isso implica que quem for usar metodoQualquer() deve ter conhecimento sobre ExceptionQualquer.

victorwss:

Basicamente o throws de metodoQualquer diz “quem for usar esse método deve se preocupar com ExceptionQualquer”. Isso implica que quem for usar metodoQualquer() deve ter conhecimento sobre ExceptionQualquer.

E se eu te disser que, em vez de usar try/catch, eu simplesmente usar “throws Exception”, compila, sem ter necessidade da minha classe “Teste2” ter conhecimento das exceções?

:!:

fabiocsi:

victorwss:

Basicamente o throws de metodoQualquer diz “quem for usar esse método deve se preocupar com ExceptionQualquer”. Isso implica que quem for usar metodoQualquer() deve ter conhecimento sobre ExceptionQualquer.

E se eu te disser que, em vez de usar try/catch, eu simplesmente usar “throws Exception”, compila, sem ter necessidade da minha classe “Teste2” ter conhecimento das exceções?

:!:

Epa! Pelo que entedi você disse que, ao usar o catch com Exception ao invés de, por exemplo, MessagingException você precisará importa a MessagingException mesmo assim? Se for isso, não é verdade.

Veja essas 2 classes baseadas no seu próprio exemplo, elas funcionam normalmente.

package packagea;
import com.sun.xml.internal.messaging.saaj.packaging.mime.MessagingException;
  
public class Exception01 {   
  
     public void lancarExcecao() throws MessagingException {   
     }   
  
}

package packageb;
import packagea.Exception01;

public class Exception02 {

	 public void testaExcecao() {   
	       
         try {   
              new Exception01().lancarExcecao();   
         } catch ( Exception e ) {   
              e.printStackTrace();   
         }   
    } 

}

É isso mesmo que você quer dizer?

Testei aqui e funciona mesmo sem os imports… porem qdo eu tirei do classpath do caso de uso a Lib do J2EE que contem as exceptions que mencionei, o compilador voltou a reclamar.

JDeveloper fundindo meu cérebro.

fabiocsi:

Testei aqui e funciona mesmo sem os imports… porem qdo eu tirei do classpath do caso de uso a Lib do J2EE que contem as exceptions que mencionei, o compilador voltou a reclamar.

JDeveloper fundindo meu cérebro.

Hehehe, mas no caso, quem ta reclamando, Teste1 ou Teste2? Teste1 precisa das exceptions no classpath para que ele possa usá-las. Acho que é isso.

Teste2 que ta reclamando :shock:

Teste1 deveria reclamar também.
Mas independente de Teste1 reclamar, Teste2 reclamará sempre. O compilador não olha apenas o nome dos métodos, o retorno e os parâmetros. Ele tem que olhar as exceções também. Daí como ele não encontra a classe. Dá erro. Mas não precisa dar import nelas se você colocar catch ou throws para Exception ou Throwable.

Imagine que isso ocorra no retorno de um método. Se metodo1 retorna ClasseA; ClasseB usa metodo1, mas sem usar o retorno (como se fosse void); e ClasseA não esteja no classpath, o compilador vai reclamar.