Nagyobb java alkalmazás fejlesztésekor elég sok nem implementált metódus (method stub) kerül a kódba, főleg a kódolás első fázisában, ezeket általában az IDE generálja, pl. mikor absztrakt osztályból származtatunk.

Ezekkel a generált metóduscsonkokkal az a gond(om), hogy általában egy return null; (vagy hasonló) utasítás szerepel bennük, ami nem a legjobb megoldás. Emellett persze oda van írva egy TODO komment, de ennek nincs sok értelme, ha senki nem figyel rá (a legjobb persze az, mikor ezt a fejlesztő kitörli, hogy ne warningoljon neki a környezet).

A return utasítás helyett szerintem sokkal jobb megoldás kivételt dobni. Ehhez nincs dedikált kivétel a Java API-ban, de érdemes írni (RuntimeException-ből származtatni), mivel így sokkal hamarabb kiderül, ha valami nincs implementálva (legkésőbb akkor, mikor szükség van a metódusra), tehát biztosan nem kell adott esetben fél órát debugolni, és biztosan nem fog az éles alkalmazásba bekerülni a metóduscsonk.

Szép dolog az eclipse, örülünk a hihetetlenül flexibilis plugin-rendszernek, és annak, hogy bármit ki tudunk hozni belőle, de azért jó, ha egyszer össze tudunk pakolni egy jó konfigot, és utána csak óvatosan piszkáljuk.

Sajnos az utóbbi időben többször tapasztaltam, hogy az ingyenes eclipse pluginok között nagyon sok az instabil. Ilyen volt a FreeMarker plugin, a SmartyPDT és a VisualSwing4Eclipse (bár erre még senki nem is mondja, hogy stabil). Sajnos mindegyik nagyon gyakran összeomlott, félúton meghalt a syntax highlight, stb. Szóval érdemes jó alaposan tesztelni, próbálgatni egy plugint, mielőtt elkezdenénk mindennapi munkánk során használni. Ha mégis felraktunk valamit, amit nagyon nem kellett volna, akkor az eclipse plugins/ és features/ könyvtárában kicsit takarítva visszaállíthatjuk az eredeti állapotot.