streamalism.org

1. Bemutatkozás

A pályázatok írásakor meghozott döntések között sokan arról szólnak, hogy mikor kell kivételt dobni, és milyen típusú dobni.

Ebben a gyors bemutatóban azt a kérdést fogjuk megvizsgálni, hogy melyik kivételt kell dobni, ha valaki áthalad a nulla paraméter az egyik módszerünkhöz: IllegalArgumentException vagy NullPointerException.

A témát úgy vizsgáljuk meg, hogy megvizsgáljuk mindkét fél érveit.

2. IllegalArgumentException

Először nézzük meg az an dobásának érveit IllegalArgumentException.

Hozzunk létre egy egyszerű módszert, amely egy IllegalArgumentException amikor átment a nulla:

public void processSomethingNotNull (objektum myParameter) {if (myParameter == null) {dobjon új IllegalArgumentException ("A 'myParameter' paraméter nem lehet null"); }}

Most térjünk át a mellett szóló érvekre IllegalArgumentException.

2.1. Így szól a javadoc a használatától

Amikor a Javadoc-ot olvastuk IllegalArgumentException, azt mondja akkor használható, ha illegális vagy nem megfelelő értéket adnak át egy módszernek. Megfontolhatjuk a nulla tiltakozzon jogellenesnek vagy nem megfelelőnek, ha a módszerünk nem erre számít, és ez megfelelő kivétel lenne a dobáshoz.

2.2. Megfelel a fejlesztői elvárásoknak

Ezután gondolkodjunk el azon, hogy mi, fejlesztők hogyan gondolkodunk, amikor veremnyomokat látunk az alkalmazásainkban. Nagyon gyakori forgatókönyv, amelyben a NullPointerException amikor véletlenül megpróbáltuk elérni a nulla tárgy. Ebben az esetben a lehető legmélyebbre megyünk a verembe, hogy lássuk, mire hivatkozunk nulla.

Amikor kapunk egy IllegalArgumentException, valószínűleg feltételezzük, hogy valami rosszat adunk át egy módszernek. Ebben az esetben megkeressük a veremben a legalsó módszert, amelyet hívunk, és onnan kezdjük a hibakeresést. Ha ezt a gondolkodásmódot vesszük figyelembe, a IllegalArgumentException közelebb kerül a veremhez, ahol a hibát elkövetik.

2.3. Egyéb érvek

Mielőtt továbblépnénk a NullPointerException, nézzünk meg néhány kisebb pontot a javukra IllegalArgumentException. Egyes fejlesztők úgy érzik, hogy csak a JDK-nak kellene dobnia NullPointerException. Amint a következő részben láthatjuk, a Javadoc nem támogatja ezt az elméletet. Egy másik érv az, hogy következetesebb a használata IllegalArgumentException mivel ezt használnánk más illegális paraméterértékekhez.

3. NullPointerException

Vizsgáljuk meg a következő érveket NullPointerException.

Készítsünk egy példát, amely a NullPointerException:

public void processSomethingElseNotNull (objektum myParameter) {if (myParameter == null) {dobja új NullPointerException ("A 'myParameter' paraméter nem lehet null"); }}

3.1. Így szól a javadoc használata

A Javadoc szerint NullPointerException, NullPointerException használat megkísérlésére szolgál nulla ahol egy tárgyra van szükség. Ha a metódus-paraméterünket nem arra tervezték nulla, akkor ésszerűen figyelembe vehetnénk ezt szükséges tárgyként, és dobhatnánk a NullPointerException.

3.2. Összhangban van a JDK API-kkal

Vegyünk egy pillanatot arra, hogy elgondolkodjunk a JDK számos olyan módszerén, amelyeket a fejlesztés során hívunk. Közülük sokan a NullPointerException ha megadjuk a nulla. Ezenkívül Objects.requireNonNull () dob egy NullPointerException ha átmegyünk nulla. Szerint a Tárgyak dokumentáció, leginkább a paraméterek érvényesítésére szolgál.

A dobó JDK módszerek mellett NullPointerException, más példákat találhatunk a Gyűjtemények API-ban található módszerektől eldobott konkrét kivételtípusokra. ArrayList.addAll (index, Gyűjtemény) dob egy IndexOutOfBoundsException ha az index kívül esik a lista méretén, és a-t dobja NullPointerException ha a gyűjtemény nulla. Ez két nagyon specifikus kivételtípus, nem pedig az általánosabb IllegalArgumentException.

Megfontolhatnánk IllegalArgumentException azokra az esetekre vonatkozik, amikor nem áll rendelkezésünkre egy konkrétabb kivételtípus.

4. Következtetés

Amint ebben az oktatóanyagban láthattuk, ez egy olyan kérdés, amelyre nincs egyértelmű válasz. A két kivétel dokumentációja átfedésben látszik abban, hogy önmagukban mindkettő megfelelőnek hangzik. További meggyőző érvek szólnak mindkét fél számára abból a szempontból, hogy a fejlesztők hogyan végezzék el a hibakeresést, valamint a JDK-módszerekben látott minták alapján.

Bármelyik kivételt választottuk, következetesnek kell lennünk az alkalmazás során. Ezenkívül hasznosabbá tehetjük a kivételeinket azáltal, hogy értelmes információkat szolgáltatunk a kivétel konstruktorának. Például az alkalmazásainkat könnyebben lehet hibakeresni, ha a paraméter nevét megadjuk a kivétel üzenetben.

Mint mindig, a példa kód elérhető a GitHubon.