Rossz gyakorlat eldobni?

1. Áttekintés

Ebben az oktatóanyagban megnézzük a következményei a fogás Dobható.

2. A Dobható Osztály

A Java dokumentációjában a Dobható osztály definíciója:az összes hiba és kivétel szuperosztálya a Java nyelvben“.

Vizsgáljuk meg a Dobható osztály:

A Dobható osztálynak két közvetlen alosztálya van - mégpedig az Hiba és Kivétel osztályok.

Hiba és alosztályai ellenőrizetlen kivételek, míg a Kivétel ellenőrizhető vagy nem ellenőrzött kivételek.

Vizsgáljuk meg, milyen típusú helyzeteket tapasztalhat a program, amikor kudarcot vall.

3. Helyreállítható helyzetek

Vannak olyan helyzetek, amikor a helyreállítás általában lehetséges, és az ellenőrzött vagy nem ellenőrzött alosztályokkal kezelhető Kivétel osztály.

Például egy program olyan fájlt szeretne használni, amely véletlenül nem létezik a megadott helyen, ami ellenőrzöttet eredményez FileNotFoundException dobják.

Egy másik példa az a program, amely engedély nélkül megkísérli elérni a rendszer erőforrásait, ami ellenőrizetlenséget okoz Hozzáférés-szabályozásKivétel dobják.

A Java dokumentáció szerint a Kivétel osztály „azokat a feltételeket jelöli, amelyeket egy ésszerű alkalmazás esetleg meg akar fogni“.

4. Helyrehozhatatlan helyzetek

Vannak olyan esetek, amikor egy program olyan állapotba kerülhet, ahol meghibásodás esetén a helyreállítás lehetetlen. Erre gyakori példa, amikor verem túlcsordulás lép fel, vagy ha a JVM memóriája elfogy.

Ezekben a helyzetekben a JVM dob StackOverflowError és OutOfMemoryErrorill. Ahogy a nevük is sugallja, ezek a Hiba osztály.

A Java dokumentáció szerint a Hiba osztály „komoly problémákat jelez, amelyeket egy ésszerű alkalmazásnak nem szabad megpróbálnia megragadni“.

5. Példa helyreállítható és helyrehozhatatlan helyzetekre

Tegyük fel, hogy van olyan API-junk, amely lehetővé teszi a hívók számára, hogy egyedi azonosítókat adhassanak hozzá néhány tárolóhoz a addIDsToStorage módszer:

class StorageAPI {public void addIDsToStorage (int kapacitás, Set storage) dobja a CapacityException {if (kapacitás <1) {dobja új CapacityException ("1-nél kisebb kapacitás nem megengedett"); } int szám = 0; while (count <kapacitás) {storage.add (UUID.randomUUID (). toString ()); szám ++; }} // egyéb módszerek itt találhatók ...}

Több lehetséges meghibásodási pont fordulhat elő hivatkozáskor addIDsToStorage:

  • CapacityException - Ellenőrzött alosztálya Kivétel amikor elhalad a kapacitás értéke kisebb, mint 1
  • NullPointerException - Nem ellenőrzött alosztálya Kivétel Ha egy null tárhely értéket adunk meg a Készlet
  • OutOfMemoryError - Nem ellenőrzött alosztálya Hiba ha a JVM-nek kifogy a memóriája, mielőtt kilépne a míg hurok

A CapacityException és NullPointerException a helyzetek kudarcok, amelyekből a program helyreállhat, de a OutOfMemoryError helyrehozhatatlan.

6. Fogás Dobható

Tegyük fel, hogy az API felhasználója csak elkapja Dobható ban,-ben próbáld elkapni amikor telefonál addIDsToStorage:

public void add (StorageAPI api, int kapacitás, Tárhely beállítása) {try {api.addIDsToStorage (kapacitás, tárhely); } fogás (dobható dobható) {// tegyen itt valamit}}

Ez azt jelenti, hogy a hívó kód a helyreállítható és helyrehozhatatlan helyzetekre ugyanúgy reagál.

A kivételek kezelésének általános szabálya, hogy a próbáld elkapni a blokknak a lehető legpontosabbnak kell lennie a kivételek elkapásában. Vagyis el kell kerülni a „mindent elkapó” forgatókönyvet.

Fogás Dobható esetünkben megsérti ezt az általános szabályt. A helyreállítható és helyrehozhatatlan helyzetek külön megválaszolásához a hívó kódnak meg kell vizsgálnia a Dobható objektum a fogás Blokk.

A jobb módszer az lenne, ha speciális megközelítést alkalmaznánk a kivételek kezelésében, és elkerülnénk a helyrehozhatatlan helyzetek kezelését.

7. Következtetés

Ebben a cikkben megvizsgáltuk a fogás következményeit Dobható a próbáld elkapni Blokk.

Mint mindig, a példa teljes forráskódja elérhető a Githubon.


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