[Javalist] Segítség! Java7 compiler BUG???

[Tamás Viktor]

Mindenben egyetertek, csak annyit tennek hozza, hogy amikor az
exception-dobast optimalizalni kell (eloregyartott exception) az szvsz
nem egy jo irany. Ilyen esetekben inkabb az exception megelozeserol
(pre-check) vagy specialis ertek visszaadasarol (NullObject/null) kell
gondoskodni.

Miert? Ahogy irtad hasznalhatatlan a stacktrace, nem lehet az
exceptionben allapotot tarolni. Lehet hogy a logikan belul is
ropkodnek az (optimalizalatlan) exception-ok, mielott dobni lehetne a
sajatot. Ha tenyleg annyira sokszor elofordul az eset,hogy
optimalizalni kell, az mar nem is kiveteles eset.
V

2012/7/25 Peter Verhas <peter at verhas.com>:
> Mesélni nem szeretek, illetve igen, de az a gyereknevelés vagy a csajozás
> témaköre, ez meg egy szakmai fórum, ahol a kőkemény tények számítanak.
> Persze szellemileg nagyon fel tud frissíteni egy olyan téma, hogy jobb-e
> exception-t dobni, vagy inkább null-t visszaadni egy metódusból amennyiben
> abból a szempontból vizsgáljuk meg, hogy melyik eredményez a hívó oldalon
> olvashatóbb kódot. Ez mindaddig szubjektív, amíg nem végzünk mérést sok
> átlagos programozón, definiált metrikával, ami méri, hogy mennyire olvasható
> a kód. Gyakorlatilag ez kivitelezhetetlen, ezért ilyenkor a common sense
> dönt; illetve az idő, ami éveket jelent. Idővel kiderül, hogy mi a jó, mi a
> rossz, és sok minden marad azon a mezsgyén, amire a legmegfelelőbb szó a
> "megfelelő".
>
> Tipikusan például ilyen a singleton. Baromi jól el lehet vitázni, hogy a
> singleton pattern, vagy antipattern (talán erről is írok majd egy
> blogbejegyzést, meg ezekből a hosszabb levelekből is), de leginkább azt
> lehet mondani, hogy nem rossz. Megfelelő. Arra amire.
>
> A tények azonban makacs dolgok, és ha mégoly szép kódot is eredményez egy
> programozási módszertan, ha használhatatlan  a kód, ami az alapján készül,
> akkor az nem egy jó pattern (ezt írtam az előző levelemben is, kedves
> néném...) Anno ezen halt el az Algol60 meg az Algol68 is: nem volt olyan
> gép, ami le tudta volna fordítani gyorsan és jól: maradt a FORTRAN a kor
> kódolóinak.
>
> Az a mondás, hogy ne dobjunk Exception-t, mert az lassú überel mindent.
> Hiába lesz szép és olvasható a kód ha egy null-t visszaadó metódus 1000-szer
> gyorsabb, mint egy olyan, amelyik egy 'new Exception()' -t dob. (kb. ez az
> arány, beleértve a try/catch kezelést is, olyan metódusoknál, amelyek
> egyébként nem csinálnak semmit).
>
> Konkrétan csak egy 'return null'-t visszaadó metódust tíz milliószor
> meghívva 12ms alatt végez a gépem, míg ugyanennyiszer egy olyat, ami egy
> Exception-t dob 23ms-ig is eltart. Hogyan?
>
> VIGYÁZAT CSALOK!
>
> Ha minden egyes alkalommal új Exception-t hozok létre, akkor ez az érték már
> 11000ms, majdnem ezerszer lassabb. De ha ugyanazt az Exception-t dobálom?
>
> Ez azt mutatja, hogy teljesítmény szempontjából nem az a kérdés, hogy null-t
> adjak-e vissza, vagy kivétel dobásával jelezzem a speciális visszatérési
> értéket, hanem azt, hogy nem feltétlenül kell minden egyes esetben új
> Exception objektumot létrehozni.
>
> Persze azt is tudni kell, hogy ilyen esetben az exception objektum stack
> trace része használhatatlan, hiszen nem azt fogja tartalmazni ahol akkor
> járt a program, amikor el lett dobva, hanem azt amikor és ahol létre lett
> hozva. A kérdés az, hogy kell-e nekünk a stack trace?
>
> Ha olyan exception-t dobunk, amelyik kivételes esetet jelez, tipikusan
> emberi beavatkozást fog igényelni, meg kell hogy jelenjen a log-ban a stack
> trace, hogy lehessen tudni, hogy honnan lett dobva, akkor létre kell hozni
> egy új exception objektumot, tipikusan a szokásos
>
> throw new Exception()
>
> pattern szerint. Amikor ezt tesszük a programnak már úgyis betették a kaput,
> a teljesítménynek nem számít, hogy a szerver X+12ms vagy X+12mp alatt áll le
> (itt X az az idő ami még ezen kívül kell a leálláshoz).
>
> Ha viszont olyan kivételt dobunk, ami nem különleges helyzet, csak jelezni
> akarjuk például, hogy nincs több adat, vagy nincs keresett adat, akkor (ha
> egyébként ez megfelel az ízlésünknek, és minden egyéb feltételnek) csak a
> teljesítmény szempontokat figyelembe véve dobhatunk egy private static final
> változóban tárolt exception-t. A metódus futási idejének csak kis része lesz
> (mondjuk 1%-a) a visszatérés maga, így ha ez kétszer annyi időt vesz igénybe
> a hívó oldalon, akkor fél százalékkal nőtt a metódus bruttó futási ideje
> (bruttó alatt a hívási oldali költségeket is figyelembe vesszük,
> try/catch/finally és társai).
>
> Ez tehát nem támasztja alá, hogy ne dobjunk exception-t nem kivételes
> helyzetben. Kicsit lassabb, de elviselhető. Ezzel némileg ellentmondok az
> Effective Java könyvnek, de nem lehet vele vitázni, mert csak annyit ír,
> hogy "egy száz elemű tömbnél az én gépemen kétszer annyi ideig tart". Ez nem
> precíz. Hidd el neki. Vagy ne hidd el, hanem mérd meg! Én erre az utóbbira
> szavazok: a konkrét méréseket, meg kódot majd felrakom a blogra, és továbbra
> is folyhat arról a vita, hogy melyik a szebb pattern: null-t visszaadni,
> vagy exception-t dobni (és persze van egy harmadik pattern is, ami azt
> mondja, hogy legyen hasNext() kinézetű metódus).
>
> --
> Verhás Péter
> peter at verhas.com
> +36(30)9306805
> skype: verhas
>
>
>
>
> On 2012.07.25., at 10:50, István Székely wrote:
>
> Sziasztok!
>
> Péter, erről légy szíves mesélj, mert úgy érzem, lemaradtam valamiről.
>
> A kivételkezelés Javaban is lassú (volt?). Ennek oka pontosan a stack trace
> összeállítása. A hívási lánc bejárása és a stack trace összeállítása igen
> drága művelet. Pont ebből az okból javasolja Joshua Bloch is, hogy
> kivételkezelést ne használjunk vezérlési szerkezetek helyett. Emiatt nem jó
> az sem, hogy az említett JPA metódus is kivételt dob null visszaadása
> helyett (persze emellett is lehet érvelni, és hajlamos is vagyok elfogadni,
> de az most más téma).
>
> Ahonnan van: Effective Java, 2nd ed
> Item 57: Use exceptions only for exceptional conditions
>
> Üdv,
> Stivi
>
>
> On 2012-07-24 23:26, Peter Verhas wrote:
>
> Technológiai okok miatt C++ és C# (általánosan .NET) környezetben nem
> szeretünk exception-t dobni (én magam programozni sem szeretek ezekben a
> környezetekben, nem is tudok (nagyon), hát még kivételt dobni). Ezekben a
> környezetekben a kivétel dobása drága, egészen más a kivételek szerkezete,
> és ezért nem is ad megfelelő információt. Tipikusan nincs benne a stack
> trace, ezért ha egy szinttel feljebb, mint ahonnan dobták nem kapjuk el,
> akkor már nem is lehet tudni, hogy honnan dobták. Akkor meg már olcsóbb
> futási időben a megfelelő hibakód visszaadása, és ennek nagy hagyománya van
> unix C és Windows C programozási környezetben, régen bevált. [Megjegyzés:
> ennek a bekezdésnek az egyik fele nem első kézből való információ, csak
> beszélgettem .NET-es kollégákkal. A másik fele viszont ezer évvel ezelőtti C
> programozási emlékek megmaradt halvány foszlányai.]
>
>
> A Java egészen más. Java-ban az exception hordozza a stack trace-t (vagy
> nem, de inkább igen, mint nem), és ebben nagyon sok szimbolikus információ
> benne van. Nem kell ott elkapni, ahol dobják, vagy egy szinttel feljebb,
> mert minden szükséges információ benne van, és ezért elég ha ott kapjuk el,
> ahol kezelni tudjuk. Ezért lett egyébként kitalálva a hiba dobás, és
> véleményem szerint a .NET környezet az exception dobás, mint pattern
> funkcionalitásának egy részét feláldozta a teljesítmény oltárán, amit
> viszont mostanra (Java6, 7) kezd túlhaladni az idő.
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>