Closed tmichel closed 10 years ago
@vbalazs egy gyors review-t majd kérhetek? különös tekintettel a UsersIMAccounts.java fájlra. Most még lehetne változtatni a hibakezelésen.
Lehetséges, hogy jobb stratégia lenne, ha az ejb rétegből runtime exception jönne és azt egy központi helyen kezelnénk le (jax-rs biztosít erre lehetőséget). Az exceptiont pedig már úgy állítanánk össze, hogy tartalmazza az összes szükséges információt, így a web rétegben tisztulhatna a dolog. Nagyjából csak "sorosítani" kéne JSON-be.
Ez talán egy pici varázslat lenne és nem lenne annyira explicit, de sokkal átláthatóbb lenne a kód. Nem kéne 2x bajlódni a hibakezeléssel. Elég lenne az üzleti rétegben figyelni erre, a web (api) rétegben meg már csak http válaszokat gyártunk.
Valamint kipróbáltam a fentebb vázolt hibakezelési módszert.
Szerintem átláthatóság szempontjából a következő lenne az ideális:
PekException
származzon a RuntimeException
-ből. Erre a nyelvi korlát/feature miatt van szükség. A business metódusokból dobálunk mindenféle exceptiont. Jó ha többféle van, hogy könnyű legyen hozzájuk http status-kódot rendelni, vagy a másik út, hogy a hibakódot le kell képezni status kóddá. Ehhez akkor kell egy konverter, ami valami alapján teszi. Mondjuk lehetne használni hibatípus, de akkor kb feltaláltuk a spanyolviaszt (java típus vs hiba típus egy stringben).
A web (api) rétegben pedig annyira leegyszerűsítjük a hibakezelést, hogy "nem lesz". Ez azt jelenti, hogy a route handler metódusokban általában nem kapunk el semmit, és hagyjuk, hogy az exception tovább gyűrűzzön és egy központi helyen elkapjuk az összes PekException
-t és json-né + hibakóddá alakítjuk, amit visszaküldünk a kliensnek.
Mi a véleményetek?
Az IM profilok (gtalk, skype, stb) listázására egy végpont.