Látott már valaki közelről J2ME-t?
Vannak olyan perverz gondolataim, hogy egy Siemens Sl45i-re megpróbálok összetákolni egy-két számomra érdekes apróságot.
Sajnos Java-val sem foglalkoztam túl sokat eddig, bár voltak apróbb, kudarcba, érdektelenségbe fulladt próbálkozásaim a témában.
Hat nezd, az a helyzet, hogy a SUN altal gyartott osztalyok is mindig exceptiont dobalnak, ha barmi kinjuk van.
Masreszt pedig sokszor jobb egy darab jol iranyzott exceptiont eldobni messzire, meg normal esetben is (pl. login failed), mint harom retegen keresztul visszateresi ertekeket vizsgalni.
Nem lehet hogy a hibakezelesi koncepciod hibas valahol?
Csomo cikk szol a kulonfele hibakezelesi strategiakrol es modszerekrol.
Az ex-kezeles a C++-ban es javaban "nagyagyu", tenyleg a kiveteles szituk miatt van. Es pont akkor elonyos, ha a throw messze esik a catch-tol.
(szvsz) tipikus hiba mostansag, hogy ex-et hajigalnak mindenfele "szokasos" esetben is, ahelyett hogy pl. visszateresi ertek, vagy az objektum statuszvaltozasa konyvelne a hiba tenyet.
Ha mindenki hajigal esz nelkul, nem csoda, ha ott allsz a 0-ban jelzett problemaval, hogy mi a turot kellene kezdeni. :)
A retry is ritkan fer ossze a kivetelekkel, legfeljebb eleg magas szintrol nezve (celszeruen a juzer kozremukodesevel).
Na igen, nagyjabol en is igy gondolom, nyilvan nagyobbak lesznek az exception osztalyok, es tobb is lesz beloluk, de ez az overhead lehet, hogy megeri.
Ugy saccolom, hogy ha sikerul elerni, hogy az exceptionok 40%-at ertelmesebben kezelje le, mint most, akkor az mar egy baromi jo eredmeny lenne.
'Alapvetoen az a problema az exceptionokkel, hogy a legtobb ember (tobbek kozott en sem) nem igazan tudja neha, mit kezdjen egy Exceptionnel.Probaljam ujra? Irjak ki egy hibauzenetet? Nyeljem le csendben? Hol kapjam el? '
A lenyeg nyilvan az hogy uj exception osztalyokat kell szarmaztatni, az Exception-bol es azok fogjak tartalmazni a szukseged infot. Az hogy milyen exception osztalyt kell csinalni, az a specifikacio es a tervezesbol kell kitalalni, mintahogy az is, hogy mit csinalj az elkapott exception-nel (hibajelzes, csendes loggolas. Ha elkaptad meg mindig ujraprobalhatod (mas feltetelekkel) meghivni a fuggenyt.
Ez persze konnyen exception osztalyok tulburjanzasahoz vezethet, mivel egy fuggveny altalaban 'keves' felekeppen sikerulhet, de sokfelekeppen 'nem' sikerulhet es ha mindent hibat rendesen deklaralalunk, akkor az szuksegkeppen ahhoz vezet, hogy egy fuggvenynek sok exception-je van. De szerintem 'better safe than sorry'.
Namost nekem az egesz programozas rovatbol ossz-vissz 7(!) topikot ir ki a listan. (Csak onnan lattam, hogy ennel joval tobb van, hogy gyanus lett, es rakerestem a JAVA szora a keresoben, es ugy, mar megmutatott egy csomo masik programozos topikot.
Na, de hat ennyit a script-hekkelessel keszult rendszerekrol :)
Nem, én nem azt mondtam,hogy rossz ötlet;) Ha egy keretrendszert csinálsz, abban nagyon korrektül le kell kezelni a dolgokat, így mindenképpen tele lesz try-catch blokkokkal. Aki majd használja eme keretrendszert, nos, neki biztos egyszerűbb dolga.
Mi fejlesztettünk (illetve folyamatosan fejlesztük) egy keretrendszert, ami mostanra eléggé 'jó' lett. Főképpen webes ( kliens lehet applet és sima browser is, server pedig servlet ), moduláris alkalmazások írásához nyújt igencsak nagy segítséget. Ilyen apróbb dolgok vannak benne, mint adatbázis connectionpool (a régebbi JDBCkben még nem volt), MQS kommunikáció, adatbázis tranzakciókezelés, blabla...
Ha a dolog többszálú, és mellesleg összetett is, akkor amúgy sem lehet megúszni azt, hogy mielőtt valamit csinálsz az objektummal, le legyen ellenőrizve, hogy az objektum milyen 'állapotban' van.
Egyébként nem specifikusan a SocketException-ra gondoltam. De pl. SocketTimeoutException (lehet újrajátszani), és a MalformedURLException (valami igencsak el lett baltázva) két külön hiba, és itt az osztály tartalmazza, hogy milyen hiba történt.
Az meg a másik, hogy lehet csinálni saját Exception osztályokat. Eléggé jól meg tudják segíteni a dolgokat.
Mert az Exception _osztalya_ nem tartalmazza ezt az informaciot.
Socket hibabol, SQL hibabol is lehet tranziens es vegleges is. Meg NullPointerException-bol is lehet tranziens (pl. masik szalon inicializalodik az objektum, es meg az adott mezo null, de ha vegere er, mar nem lesz az)
Masreszt pedig ennek jo lenne egy egyseges keretet adni. Ne kelljen mindent telehintenem try-catch-ekkel, kulonosen akkor, amikor threadpoolban dolgozom, tehat a hivo csak berakja egy queue-ba a feladatot, az kesobb hajtodik vegre aszinkron modon.
El lehet különíteni azt, hogy mit lehet megismételni (pl. egy socekt kommunikáció időtúllépés miatt nem válaszol - NEM_OLYAN_GAZ), attól, hogy mit nem lehet megismételni (pl. adatbázis SQL hiba, pl. érvénytelen oszlopnév - VEGZETES HIBA).
Gyerekek, mar az 1.4.1-es jdk-nal tartunk, es meg senki sem nyitott rola topikot? :)
Na, akkor inditok egy nagyon specifikus temaval: exception kezeles.
Alapvetoen az a problema az exceptionokkel, hogy a legtobb ember (tobbek kozott en sem) nem igazan tudja neha, mit kezdjen egy exceptionnel. Probaljam ujra? Irjak ki egy hibauzenetet? Nyeljem le csendben? Hol kapjam el?
Egy atlagos exception tul keves adatot tartalmaz ahhoz, hogy ertelmesen lehessen lekezelni. Pl. en igenis raknek bele retry infot. (Tehat hogy erdemes-e ujraprobalni, tranziens hibarol van-e szo, vagy vegleges es megmasithatatlan hibarol, ha igen, hanyszor, mennyi idokozonkent.
Erre lehetne irni egy egesz kis keretrendszert, egy intelligensebb threadpool-implementacio kereteben. Ha lesz idom, neki is allok :)