Mida teeksite, kui A meetodi kutsumisel tekib erand?

Sõltuvalt eranditüübist ja äriloogikast:

1. Erandi töötlemine (try-catch): Püüa erand catch plokis ja tee sobiv loogika:

   • Vea logimine.
   • Teate kuvamine kasutajale.
   • Püüa taastuda või jätkata tööd (näiteks pakkudes vaikimisi väärtust).
   • Muuta erand sobivamaks (Checked unUnchecked).

   try {
       methodA();
   } catch (SpecificException e) {
       // Vea logimine
       logger.error("Viga methodA kutsumisel", e);
       // Võime näidata kasutajale sõnumi
       // displayErrorMessage("Viga tekkis");
       // Või proovida taastuda
       // handleRecoveryLogic();
   } catch (AnotherException e) {
       // Teise tüüpi erandi töötlemine
   } finally {
       // Kood, mis käivitatakse igal juhul (ressursside vabastamine)
       // closeResource();
   }
   

2. Erandi viskamine (throws): Kui meetod A ei saa ise erandit töödelda, viskab ta selle edasi kutsuvale meetodile throws abil. Kutsuv meetod peab siis kas töötlema selle või edasi viskama:

   public void methodB() throws SpecificException {
       methodA(); // methodA võib visata SpecificException
   }
   

   See kehtib, kui erand nõuab kõrgemal tasemel töötlemist.

3. Erandi ignoreerimine (mitte soovitatav): Püüa erand ja tee selle kohta mitte midagi. See on halb tava, kuna see varjab vigu ja raskendab silumist. Väga harva on see õigustatud, kui tegemist on väheolulise ja tööle mõjuva erandiga.

   try {
       methodA();
   } catch (Exception e) {
       // Ignoreeri... väga halb mõte enamikul juhtudel
   }
   

4. Töö katkestamine: Kui erand on fataalne ja edasine töö on võimatu, võib selle levitada või selgelt visata uue erandi, näiteks RuntimeException, kui vaja töövoogu peatada.

Valik sõltub kontekstist, erandi tüübist (Checked vs Unchecked) ja vigade töötlemise poliitikast.

Oluline on, et erandite töötlemine oleks järjepidev ja pakuks piisavat teavet silumiseks.