exception handling, porównanie sposobów

Witajcie, mam 2 proste pytania, gdyż dopiero przesiadłem się z cepy na Javę, a za parę dni mam egzamin poprawkowy, pomocy:)

Czy poniższy sposób :

public void metodaA()throws ArithmeticException
{
        int a =0;//lub wczytaj z klawiatury..
        try{
        int b= 32/a;       
        }catch(ArithmeticException e){
        	System.out.println("No przez zero to nie wolno");
        }
}

czy też:

public void metodaA()
{
        int a =0;//lub wczytaj z klawiatury
       	if(a != 0){
       		int b= 32/a;
        }
       	else throw new ArithmeticException();
}

podczas,gdy w przy wywoływaniu metody:

cWyjatek w = new cWyjatek();

try {
     w.metodaA();              
}catch(ArithmeticException e){
     System.out.println("Nie wolno");
                                

oba w konsekwencji zgłaszają wyjątek poprawnie, więc czy jest różnica? Czy jeżeli wiem,że w danej metodzie jest "podejrzany" kod, to nie lepiej zawsze opisać metodę z throws i potem wywoływać ją bez bloku try/catch? Właściwie jeśli jest to taki fragment kodu, dla którego Wyjątek przewiduję czysto z logiki mojego programu...

...bo zauważyłem,że w niektórych przypadkach (niżej) kompilator jakby wyłapuje niebezpieczną sytuację i i tak podsuwa mi konieczność zastosowania throws w nagłówku metody, I DOPIERO PODCZAS WYWOŁYWANIA mam za konieczność stosowanie try/catch, czego robić nie musiałem przy wywoływaniu metodaA, gdyż kompilator o to mnie nie prosił.

public void metodaB() throws ArithmeticException,Exception
{
    out = new BufferedWriter(new FileWriter("outfilename"));
    
    out.close();  
    int a = 0;
    int b = 32 / a;
    out.write(a);	
    out.write(b);
}

Więc co, raz muszę wywoływać metodę w try/catch, raz nie muszę, jak jest z tym ?
i czy jeśli kompilator mnie nie zmusza to stosowania w nagłówku throws to i tak lepiej jest to robić, czy właściwie nie ma różnicy?

Wyjątki dziedziczące po RuntimeException i po Error nie muszą być wypisywane w throws. Wypisywanie reszty jest wymuszane przez kompilator.

Aha, rozumiem, dzięki.

ok a co z pierwszą częścią zapytania? Czy jest wszystko jedno w jakiej wersji metodaA będzie zaimplementowana?

Przecież pierwsza wersja nie rzuca ArithmeticException nigdy, a druga wersja może rzucić, więc oczywiście te funkcje nie działają tak samo.

więc co wykonuje linijka

   else throw new ArithmeticException();

?
Po odpaleniu ukazuje mi się odpowiednia informacja w konsoli, jakoby wyjątek był obsłużony. Czy więc jest to źle jednak?

Drugie rozwiązanie wydaje się lepsze, bo masz oddzieloną logikę od prezentacji.

rybsa33 napisał(a):

więc co wykonuje linijka

   else throw new ArithmeticException();

?

Rzuca nowy wyjątek.

W pierwszej wersji z metody nie jest rzucany ArithEx tylko od razu obsłużony i jest wypisany komunikat od razu i w metodzie wywołującej nie zostanie już ten wyjątek wychwycony, a w drugiej wersji jest rzucanie wyjątku poza metodę metodaA(), który jest następnie łapany przez metodę wywołującą i tam obsługiwany. Różnica jest przecież oczywista.

AA czaję, dzięki, czyli tak właściwie poprzez obsłużenie błędu rozumiemy kod wykonany w bloku catch, racja?
I obsłużyć mogę nawet 2 razy np.

public void metodaA() throws ArithmeticException{
        int a =0;
        try{
        int b= 32/a;
        }catch(ArithmeticException e){
        	System.out.println("Obsluga bledu");
        	throw e;
        }
}

i potem drugi raz obsługa przy wywołaniu

                        try
                        {
                        w.metodaA();             
                        }catch(ArithmeticException e){
                        	System.out.println("Obsluga2");
                        }

Tylko tak na prawdę to w jakich sytuacjach zachodzi potrzeba takiego podwójnego łapania (obslugi)?

Łapanie i rzucanie przydaje się na przykład przy opakowywaniu błędu, np łapiesz IOException i pakujesz go w swój LoginException, dzięki czemu wywołujący twoją metodę nie muszą znać flaków twojej metody i oczekiwać po prostu LoginException przy jakimś problemie z logowaniem. Zastosowania mogą być też inne.

Przez pakowanie exceptiona rozumiem wrzucanie jednego exceptiona w konstruktor następnego.