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.


$config[zx-auto] not found$config[zx-overlay] not found