Különbség a dobások és a dobások között a Java-ban
1. Bemutatkozás
Ebben az oktatóanyagban megnézzük a dobás és dob Java-ban. Megmagyarázzuk, mikor kell mindegyiket használni.
Ezután bemutatunk néhány példát az alapvető használatukra.
2. Dobás és Dobások
Kezdjük egy gyors bevezetéssel. Ezek a kulcsszavak a kivételkezeléshez kapcsolódnak. Kivételek akkor merülnek fel, ha az alkalmazás áramlási rendje megszakad.
Ennek sok oka lehet. A felhasználó rossz bemeneti adatokat küldhetett el. Megszakadhat a kapcsolat, vagy más váratlan helyzet állhat elő. A kivételek jó kezelése kulcsfontosságú ahhoz, hogy alkalmazásunk működni tudjon a kellemetlen pillanatok megjelenése után.
Használunk dobás kulcsszóval kifejezetten kivételt vethet a kódból. Lehet bármilyen módszer vagy statikus blokk. Ennek a kivételnek a Dobható. Ez lehet a Dobható maga. Nem dobhatunk több kivételt egyetlenével dobás.
Dobások kulcsszó elhelyezhető a metódus deklarációban. Jelzi, hogy mely kivételek vonhatók le ebből a módszerből. Ezeket a kivételeket próbálkozással kell kezelnünk.
Ez a két kulcsszó nem cserélhető fel egymással!
3. Dobás Java-ban
Vessen egy pillantást egy alapvető példára, kivéve a módszert.
Először is képzelje el, hogy egy egyszerű számológépet írunk. Az egyik számtani művelet az osztás. Ezért felkértek minket a szolgáltatás megvalósítására:
nyilvános kettős osztás (dupla a, dupla b) {return a / b; }
Mivel nem lehet osztani nullával, hozzá kell adnunk néhány módosítást a meglévő kódunkhoz. Úgy tűnik, ez egy jó pillanat a kivétel felvetésére.
Csináljuk:
nyilvános kettős osztás (dupla a, dupla b) {if (b == 0) {dobjon új ArithmeticException-t ("Az osztó nem lehet egyenlő nullával!"); } return a / b; }
Mint láthatja, használtuk Számtani kivétel tökéletesen megfelel igényeinknek. Áthaladhatunk egyetlen Húr konstruktor paraméter, amely kivétel üzenet.
3.1. Jó gyakorlatok
Mindig a legkonkrétabb kivételt kell előnyben részesítenünk. Találnunk kell egy osztályt, amely a legjobban illik a kivételes eseményünkhöz. Például dobni NumberFormatException ahelyett IllegalArgumentException. Kerülnünk kell egy nem specifikált dobást Kivétel.
Például van egy Egész szám osztályban java.lang csomag. Vessünk egy pillantást a gyári módszer deklarációjára:
public static Integer valueOf (String s) dobja a NumberFormatException értéket
Ez egy statikus gyári módszer, amely létrehoz Egész szám például Húr. Helytelen bemenet esetén Húr, a módszer dobni fog NumberFormatException.
Jó ötlet, hogy meghatározzuk saját, leíróbb kivételünket. Miénkben Számológép osztály, ami lehet például DivideByZeroException.
Vessünk egy pillantást a minta megvalósítására:
public class DivideByZeroException kiterjeszti a RuntimeException {public DivideByZeroException (String üzenet) {super (üzenet); }}
3.2. Meglévő kivétel becsomagolása
Néha egy meglévő kivételt be akarunk vonni az általunk meghatározott kivételbe.
Kezdjük a saját kivételünk meghatározásával:
a nyilvános osztály DataAcessException kiterjeszti a RuntimeException {public DataAcessException (karakterlánc üzenet, dobható ok) {super (üzenet, ok); }}
A konstruktor két paramétert vesz fel: kivételüzenetet és okot, amely bármelyik alosztálya lehet Dobható.
Írjunk egy hamis megvalósítást Találd meg mindet() funkció:
public List findAll () dobja SQLException {dobja új SQLException (); }
Most SimpleService hívjuk meg a repository függvényt, aminek eredménye lehet SQLException:
public void wrappingException () {try {personRepository.findAll (); } catch (SQLException e) {dobja új DataAccessException ("SQL Exception", e); }}
Újra dobunk SQLEkivétel nevű saját kivételünkbe csomagolva DataAccessException. Mindent a következő teszt igazol:
@Test void whenSQLExceptionIsThrown_thenShouldBeRethrownWithWrappedException () {assertThrows (DataAccessException.class, () -> simpleService.wrappingException ()); }
Ennek két oka van. Először is kivételcsomagolást használunk, mert a kód többi részének nem kell tudnia a rendszer minden lehetséges kivételéről.
A magasabb szintű komponenseknek sem kell tudniuk az alsó szintű komponensekről, sem az általuk dobott kivételekről.
3.3. Többfogás Java-val
Előfordul, hogy az általunk alkalmazott módszerek sokféle kivételt hozhatnak.
Vessünk egy pillantást egy átfogóbb try-catch blokkra:
próbáld ki a {tryCatch.execute () parancsot; } catch (ConnectionException | SocketException ex) {System.out.println ("IOException"); } catch (Exception ex) {System.out.println ("Általános kivétel"); }
A végrehajtani módszer három kivételt vethet fel: SocketException, ConnectionException, Exception. Az első fogási blokk elkap ConnectionException vagy SocketException. A második fogási blokk elkapná Kivétel vagy bármely más alosztálya Kivétel. Emlékezz arra előbb mindig részletesebb kivételt kell kifognunk.
Felcserélhetjük a fogási blokkok sorrendjét. Akkor soha nem fognánk el SocketException és ConnectionException mert minden a fogásig fog menni Kivétel.
4. Dobások Java-ban
Hozzátesszük dob a módszer deklarációhoz.
Vessünk egy pillantást az egyik korábbi módszer deklarációnkra:
public static void execute () dobja a SocketException, ConnectionException, Exception elemeket
A módszer több kivételt is felvethet. A metódusdeklaráció végén vesszővel vannak elválasztva. Mindkét, bejelölt és ellenőrizetlen kivételt beilleszthetjük a dob. Az alábbiakban leírtuk a köztük lévő különbséget.
4.1. Ellenőrzött és nem ellenőrzött kivételek
Az ellenőrzött kivétel azt jelenti, hogy a fordítás idején ellenőrzik. Ne feledje, hogy ezt a kivételt kezelnünk kell. Ellenkező esetben a metódusnak meg kell adnia egy kivételt a használatával dob kulcsszó.
A leggyakoribb ellenőrzött kivételek a következők IOException, FileNotFoundException, ParseException. FileNotFoundException dobhat, amikor létrehozunk FileInputStream tól től File.
Van egy rövid példa:
Fájlfájl = új Fájl ("not_existing_file.txt"); próbálja meg a {FileInputStream stream = new FileInputStream (fájl); } catch (FileNotFoundException e) {e.printStackTrace (); }
Hozzáadással elkerülhetjük a try-catch blokk használatát dob a módszer deklarációhoz:
private static void uncheckedException () dobja a FileNotFoundException {File file = new File ("not_existing_file.txt"); FileInputStream stream = új FileInputStream (fájl); }
Sajnos egy magasabb szintű funkciónak még mindig kezelnie kell ezt a kivételt. Ellenkező esetben ezt a kivételt a metódus deklarációba kell beírnunk dob kulcsszót.
Ellenkezőleg: a nem ellenőrzött kivételeket a fordítás idején nem ellenőrzik.
A leggyakoribb ellenőrizetlen kivételek a következők: ArrayIndexOutOfBoundsException, IllegalArgumentException, NullPointerException.
A nem ellenőrzött kivételeket futás közben dobják el. A következő kód a NullPointerException. Valószínűleg ez az egyik leggyakoribb kivétel a Java-ban.
A metódus null hivatkozásra való meghívása ezt a kivételt eredményezi:
public void runtimeNullPointerException () {String a = null; a.hossz (); }
Ellenőrizzük ezt a viselkedést a tesztben:
@Test void whenCalled_thenNullPointerExceptionIsThrown () {assertThrows (NullPointerException.class, () -> simpleService.runtimeNullPointerException ()); }
Ne feledje, hogy ennek a kódnak és a tesztnek nincs sok értelme. Csak tanulási célokra szolgál a futásidejű kivételek magyarázatára.
A Java-ban a Hiba és RuntimeException ellenőrizetlen kivétel. A bejelölt kivétel minden más a Dobható osztály.
5. Következtetés
Ebben a cikkben két Java kulcsszó különbségét vitattuk meg: dobás és dob. Átnéztük az alaphasználatot és beszélgettünk egy kicsit a jó gyakorlatokról. Aztán beszélgettünk ellenőrzött és ellenőrizetlen kivételekről.
Mint mindig, a forráskód megtalálható a GitHub-on.
Ha mélyebbre szeretne térni a Java-ban végzett kivételkezelésben, kérjük, olvassa el a Java-kivételekről szóló cikkünket.