Egyszerűen csak nem akarsz megjegyezni mindent, sőt, még csak tudni se akarsz róla.
Sok embernek ez a megoldás tetszik, mert egyszerűnek látszik. Az ilyen megoldással lehet írni a rossz minőségű kódokat.
Ugyanez Javaban elhagyható - az egész cuccot beteszed egy try-catch blokkba, és minden szépen "elintéződik" anélkül, hogy gondolkodni kellene.
Tudom, hogy minden példa rossz, de ez ugyanolyan megoldás, mint amikor a 24 tételes vizsga esetén úgy egyszerűsítesz, hogy 20 tételt kihagysz. 4 tételt sokkal könnyebb megtanulni, mint 24-et!
Nézzünk egy programozási példát!
public BlogPost update(...) {
storage.store(post);
tempFileService.removeTempFile(post.fileName);
}- Szép egyszerű megoldás!
- Valóban?
- Nem. ;-)
A gond az vele, hogy a store hibája esetén nem törli a temp fájlt.
- Persze, hisz try-catch-be kellene rakni a store-t!
- Miért? Minden sort try-catch-be kell rakni?
- Nem, hülye, csak azt ahol hiba lehet és fontos, hogy az utána levők is lefussanak.
- Ja, OK, de honnan tudom, hogy a store-ben hiba lehet?
- Szól az IDE (Checked exception).
- Itt most nem szól.
- Akkor ott van a store dokumentációjában, hogy RuntimeExceptiont dob.
- Itt nincs ilyen.
- Akkor nézd meg a store forrását.
- A storage egy interféce.
- Akkor keresd meg, hogy mi implementálja.
- Megvan, csak ennyi van benne: repository.save(post). Itt se szól az IDE és nincs a doksiban sem, persze a repository is interfész.
- Kutakodj tovább!
- Megvan, CrudRepository.save. Itt se szól az IDE és nincs a doksiban sem, persze ez is interfész.
- Kutakodj tovább!
- Megvan, SimpleJpaRepository. Ez már nehezebb volt, mert a neten kellett keresgélnem. Ebben az EntityManager persist és merge metódusát hívja. Azoknál sem szól az IDE, de a doksiban benne van, hogy EntityExistsException-t, IllegalArgumentException-t és TransactionRequiredException-t is dobhat.
- Na látod! Ezért kell azt belerakni try-catch-be. Máskor ne légy ilyen figyelmetlen, minden sort kövess vissza! Ilyen egyszerű ez, ha megakarod érteni, hogyan is működik ténylegesen!