Pa enkapsulacija je los termin za ovo, gutanje je ispravan termin
Medjutim, to je veoma veoma losa praksa, exceptioni imaju svoju svrhu, oni signaliziraju ne samo gresku, nego i informaciju da je proces nedovrsen i nekompletan i da je buduce stanje tvog procesa time mozda osteceno. Kad progutas exception, ti dalje signaliziras da je to sasvim OK i da je tvoj deo procesa dobar bez obzira na to i neki put se koristi, ali ne u obliku u kojem ga ti dajes ovde, sa gutanjem SVIH mogucih exception-a, vec sa gutanjem odredjenog specificnog exceptiona. Kad progutas exception, kod koji je pozvao tebe smatra da si ti ispravio situaciju i smatra da je stanje tvog procesa stabilno, sto uopste ne mora biti slucaj. Ovo moze da dovede do suludih bagova koje je VEOMA tesko uloviti jer taj catch uvek guta exception. Moras da prebacis deugger da hvata exceptione u trenutku bacanja i onda da debagujes aplikaciju dok ona puca na svim mogucim i handlovanim i nehandlovanim exceptionima.

Dalje, uvek postoji top-level exception handler koji hvata sve exceptione koji procure iz koda. TO je onaj dijalog za winforms aplikacije i zuta strana za asp.net aplikacije. Cilj jeste izbeci pojavljivanje tog hendlera, ali ne po svaku cenu i ne tako sto ces na mufte da progutas exception samo da se ne bi pokazao Ja kad god vodim projekat ocekujem VEOMA dobro objasnjenje za try/catch() i try/catch(Exception) i do sad jos nisam cuo ni jedno.




Ovo nije izvodljivo ni u jednom jeziku koji ja znam, pa ni ovde. Da bi to moglo da funkcionise CLR bi morao da zna koje sve exceptione metod moze da baci sto nije zapisano u CLS metadata bloku. To sto ti znas da metod moze da baci npr FileNotFoundException je zato sto si procitao u MSDN-u, takva informacija ne postoji na nivou binary-a i samim tim nija raspoloziva kompajleru. Jedini jezik koji ima "specify" strukturu je Java, gde moras da navedes koje unchecked exceptione tvoj metod moze da izbaci "van sebe", tj one koje koje moze da izbaci a koje ti nisi handlovao sa catch unutar metoda. Medjutim i ta informacija, iako ide u Java klasu se ne moze koristiti za gornju svrhu, vec verovatno sluzi Java interpreteru za interno funkcionisanje.

Nisam siguran da je bas samo interno.. Ja kada sam nesto malo radio u Javi, Eclipse nije hteo ni da cuje da napisem nesto a da iskuliram exception-e iz te liste i trazio je ili da ja navedem da i moja klasa "baca" te iste exception-e ili da ih handle-ujem. E sad, da li je to do Jave ili Eclipse-a - nemam pojma :)

To je do Jave. I mislim da je interno zato sto ne postoji nacin na koji ti mozes da iskoristis to, sem kao eventualno informacija za tebe dok pises metod sta sve moze da te snadje iz pozivanih metoda, pa da mozes da handlujes nesto od toga ako hoces. Razlog zasto si ti morao da navedes te exceptione ako ih ne handlujes je da bi se ta informacija propagirala dalje za kodere koji pozivaju tvoj metod, posto ti ne handlujes taj exception onda moze da se desi da taj exception premota stack u njegov kod

Mislio sam na enkapsulaciju jer nekad, kada nema dokumentacije ja treba da ulazim u code i da gledam gde se sta baca od exceptiona, to mi je bila poenta, sto nekad za exception programer mora da se udubljuje u code ako ga ima ili da razmislja o njemu ako ga nema

No i dalje me muci to sto nema neki lagan mehanizam da se hadluju greske koje izaziva iskljucivo poziv jedne metode, bas zbog ovoga, pa sam zato pitao koliko je moguce u buducnosti da se namesti tako nesto, jer upravo ono sto si spomenuo mene muci (jbg. lenj sam ), jednostavno moram da ulazim MSDN da vidim sta baca ili u neciji code.

Imam jos jedno pitanje



Znaci gutam sve exceptione koje baca File.Open, jer me interesuje samo da li je uspelo ili nije.

I sad koliko je to isto sto i jedan general catch, koja je tacno razlika? Sta sve moze da se uhvati jedan general exception za razliku od ovih navedenih? (pretpostavljam da jos neko moze da baci exception, OS, CLR u metodi)

Sad me bas bilo zainteresovalo kako i sta radi J# posto on "forsira" checked exceptione zbog kompatibilnosti, a sam CLS nema podrsku za checked exceptione



Kad se Bacac() rafaktoruje u C# dobija se sledece:


Sto ce reci, J# kompajler je sadista i tera te da prijavljujes exceptione iako nicemu ne sluzi to prijavljivanje

Nasao sam jos jedan komentar nekog lika:


Rod Waldhoff je lepo objasnio u svom blogu zbog cega su Java checked excpetioni u stvari van mozga

Ne mora. To je "lepota" exception-a. Tebe ce interesovati handlovanje odredjenog exceptiona AKO I SAMO AKO znas kako da ga handlujes da ispravis tok aplikacije. Ako ti ne znas, onda taj exception propagira na gore dok ne nadje nekog KO ZNA, i nema potrebe da ti lomis glavu oko toga. Ako niko ne zna, uhvatice ga glavni catch aplikacije u frameworku i utepace ti aplikaciju uz prigodan prozor, sto je sasvim primereno posto niko usput nije zna sta da radi sa tim.




Otkud znas da je uspelo kad si progutao sve exceptione .

Generalni catch ima isti efekat kao catch(Exception ex), samo sto nemas ex da se s'njime poigras . Razlika izmedju hvatanja specificnih exceptiona za koje ti MSDN kaze da mogu da nastanu i svih exceptiona je u tome koliko verujes MSDN-u Tvoja aplikacija mozda bude pokrenuta na .NET frameworku 6.0 koji sad za promenu baca i SomeFutureException koji ti ne znas da handlujes (ko da ti sad i handlujes ova tri) i koji treba da preskoci tvoj catch. Ako hvatas sa catch(Exception) onda ce i on biti "handlovan", sto nije dobro.

mmix nisam siguran da smo se razumeli oko ovoga


Recimo, imam metodu koja ce bacati exception ja treba njene exception-e da uhvatim i uradim nesto sa njima, u MSDN imam dokumentaciju, ali kada radim sa tudjim kodom ja je nemam, a recimo metoda baca exception i u slucaju exception-a ja znam sta cu da radim i to mislim iskljucivo na exceptione od te metode, ne general exception. Hocu da kazem da kada treba da pozovem neku metodu mene interesuje samo da li je ona uspesna ili ne, na stari nacin preko return value (pogotovo ako je bool) ja eksplicitno preko deklaracije f-je vidim da li je nesto uradjeno ili nije, ili recimo ako je kao u C++-u gde postoji nesto kao succeed ili tako nesto, zaboravio sam sada, sto sve znaci da mogu na osnovu nekog "nepisanog" (ili pisanog?) pravila da znam unapred da li je dobro ili ne

Nadam se da ne davim mnogo, uglavnom, ovaj deo oko hvatanja general exceptiona je jasan, hteo sam da vidim da li postoji opravdan slucaj u nekim situacijama tako da... sada je to razreseno. Jos nesto me interesuje da li posedujes neki link sa objasnjenom implementacijom exception-a u .NET, ja sam svojevremeno trazio ali nisam nista nasao, jedino sto sam negde procitao je da se oslanja na win-ov SEH mehanizam.

SEH je skraceno od structured exception handling, i nije deo windowsa, samo je bar za sada predominantni sistem u upotrebi na windows platformi, to je jednostavno cross-language coding pattern koji je implementiran u jezgro .net CLR-a, slican postoji u runtime-u C++ i Jave, pa je ujedno i najrasprostranjeniji exception mehanizam, medjutim svaka aplikacija ima svoju instancu ovog engine-a, to nije servis koji pruza OS.

Svaki metod koji ima try strukturu publikuje u IL-u metode maping informaciju o adresama kodova koji ulaze u strukturu:



publikuje ovo u MSIL:

.try L_0008 to L_0017 catch [mscorlib]System.FieldAccessException handler L_0017 to L_0024
.try L_0008 to L_0017 catch [mscorlib]System.StackOverflowException handler L_0024 to L_0031
.try L_0008 to L_0034 finally handler L_0034 to L_0049



Na osnovu ovog CLR pravi strukturu za premotavanje steka i pretrazivanje handlera.

Znam za SEH, i mislio sam da je to defaultna implementacija na win-u, ako se ne varam na svaki thread stack ima svoj EXCEPTION_REGISTRATION stukturu u kojoj se nalazi callback f-ja ako nesto krene lose, koliko znam C++ prosiruje tu struktruru i kompajler dodatno "optimizuje" exceptione tj. try blokove, ako se ne varam. Uostalom evo link koji sam bio nasao pa ako nekog interesuje...
http://www.microsoft.com/msj/0197/exception/exception.aspx

i za C++
http://www.codeproject.com/KB/cpp/exceptionhandler.aspx

To je Win32 SEH koji koristi API. .NET CLR (ako se ne varam, a treba da proverm, na spisku mi je zajedno sa x64 SEH) u FS:[0] upucava handler VAN steka da bi uhvatio exception koji potice iz Win32 API-a bez da unwinduje svoj managed stek, i ima svoju implementaciju SEHa koja ide preko steka.

Kad smo kod x64, doslo je do drasticne promene Win64 SEH-a u odnosu na WIn32. Ako te interesuje imas detalje na:

Exceptional Behavior - x64 Structured Exception Handling:
http://66.102.9.104/search?q=c...om/article.cfm%3Farticle%3D469


link ide kroz google cache da ne bi morao da se registrujes na ovom sajtu (mrzim takve sajtove, crawlere pusta a usere smara).

google je tata

Hvala na linku, naravno da me interesuje

Ako ih dovoljno mrzis, mislim da mozes da ih prijavis. Znam da je pre izvesnog vremena Google banovao sajtove koji to rade.

Time bih nazalost vise izgubio nego dobio jer onda ne bi bilo ni kesirane verzije :)