može. mani se Jave i bavi se C-om.

ili ubaci throws statement u deklaraciju metode ili koristi neki
kvalitetniji editor koji će automatski ubacivaty catch za svaki
exception koji tvoja metoda može da napravi. Eclipse to radi odlično,
verovatno i NetBeans, nisam ga koristio.

To radi i JIntelli Idea, posebno sto on to i sakriva tako da kod izgleda preglednije.

zašto?

zbog ovog zaključka:

u C-u ne moraš imati nikakav error handling da bi ti se progam iskompajlirao. istina da neće raditi, ali to valjda nije ni bitno ako si se rešio try..cYtch (kič?) blokova.

http://java.sun.com/docs/books...ential/exceptions/runtime.html

Hibernate i Spring, recimo, ispaljuju unchecked izuzetke i onda je jako zgodno raditi sa njima. A opet mozes da uhvatis odredjeni izuzetak ako zelis, na bilo kom nivou. I onda ga recimo wrapujes u neki svoj biznis checked izuzetak i odradis rethrow..

realno try/catch blok je mnogo bolji nego funkcije koje recimo vracaju int i ako je taj int <0 onda je pitanju neka greska itd.... ali kao sto je vec receno svaki danasnji IDE radi posao savreseno dobro po tom pitanju. Da ne postoji mogucnost nekog nepredvidjenog izuzetka ne bi morao da ga hvatas. Tvoja je stvar samo da li umes da ga obradis ili ces pak samo da ga logujes.

Ne znam sta imas protiv try-catch. Mislim da to pojednostavljuje kod u mnogo slucajeva. Mozes da izbegnes uslove(if) na elegantan nacin.

malo ste krivo shvatili, možda nisam dobro objasnio.

recimo radio sam konekciju na bazu i bez try-cytch blokova se pojave greške, koriste se 3 bloka!
na ono što sam mislio kao što je u .net-u.
bez blokova i ako je takva situacija da trebaju, onda se stavljaju.
naravno ako je dijeljenje sa 0 da se moraju staviti.
u vs 2008 ako se dijeli sa 0 ne treba blok.
tako je i u javi od prije!

umjesto rezultata se pojava infinitivy(beskonačno)!

Ja se ne secam kad je u javi bilo dozvoljeno delenje sa 0(nulom). Mozda nikad nisam ni pokusao :D
A to sto u .NET-u ne moras da stavljas try-catch blokove ja uopste ne vidim kao prednost. I nisam jedini.

Ne samo sto mi je drago sto sam prisiljen da ih stavljam(jer bi ih zaboravio) nego i sam pravim svoje izuzetke i rukujem sa njima onako kako mislim da mi je potrebno. Cesto poludim kad mi se nesto desi a ja nit sam bacio niti uhvatio izuzetak.

I kao sto Dejan Lozanovic rece, IDE ti sve sam odradi, lagano ko pesmica.

javi nije potrebno (bolje reci obavezno) deljenje sa nulom stavljlati u try catch blok, zato sto je izuzetak koji se generise u tom slucaju (ArithmeticException) runtime exception

moze i ovako ( bez nervoze)



Necemo da pocinjemo flame war, ali Java je moderniji jezik od C (a pisana je u C ) i u principu je dobro koncipirana

He,he. Kad smo vec kod tih blokova, imam jedno pitanjce. Razumem kako radi try-catch (proverava prilozeni zraz da li je dobar), razumem i statment-throws (naglasava da se MOZE pojaviti greska u kompajliranju , ali nisam najbolje razumeo distinkciju nje sa thrown statement i kada se ona upotrebljava?
Hvala

Ne znam za thrown ali si verovatno mislio na throw.


Kad kazes throws u potpisu metode time deklarises da ta metoda moze baciti taj izuzetak i time obavestavas buduce korisnike te metode o potencijalnoj gresci.

throw je naredba kojom bacas exception u tvom programu kada ti mislis da je prikladno.

Recimo ako napises x/0 java ce sama baciti exception jer deljenje sa nulom je nemoguce uvek i svuda, ali ako ti je neko uneo string koji se ne sastoji samo od cifara a trebalo bi java ne moze sama provaliti da tu treba baciti izuzetak nego ces morati ti da kezes throw new TajITajIzuzetak()

aha, dakle u ovom kodu:

public void readMessage() throws IOException {
MessageReader mr = new MessageReader();
try {
mr.loadHeader();
} catch (IOException e) {

throw e;
}
}

throw e -- ovde znaci da ukoliko provera "try" pokaze da je ova metoda sa greskom, da uhvati gresku i kreira objekat tipa Exception, koji podrazumeva taj i taj izuzetak ako se desi. Jel tako?

Ne bas, mada te mozda nisam razumeo :)

Ako se u metodi

desi izuzetak(kakav god) taj izuzetak se propagira do prvog try/catch bloka koji ga hvata.



U ovom catch delu ti hvatas IOException(recimo da ne postoji fajl koji citas) i sad imas izbor sta dalje. Mozes daga ispise negde, da pokusas ponovo da otvoris fajl, a mozes i da propagiras izuzetak. Recimo ovde ga zabelezis u log, cisto da znas da se desio o kad, plus propagiras ga do recimo GUI-a gde ces rukovati s njim tako da ces izvuci korisnu informaciju iz izuzetka i prikazati korisniku.

npr:

Da, ok. To razumem, ali sta oznacava ovo na kraju- throw e? Mislim sta bacam kada sam u bloku vec utvrdio da li je bilo greski a ako jeste izbacio sam logger.error(e). Cemu onda ovo throw e?

pošto ga je tvoj try..catch uhvatio, izuzetak se smatra obrađenim. ako
sad opet pozoveš throw sa istim tim izuzetkom ti ga opet proizvodiš i
time postižeš da se on obradi u drugom try..catch bloku koji se u
hijerarhiji nalazi "pre" ovog tvog iz metode (verovatno u nekoj drugoj
metodi koja je pozvala ovu tvoju readMessage). zbog toga se u
deklaraciji readMessage nalazi throws IOException. da nema tog throw e
ne bi trebalo da pišeš ni throws.

Ti mene zezas ili sta? :)




Treba ti i ovo:


Dakle, ovu gresku dobijes u recimo klasi koja otvara i cita datoteku. Sadrzaj datoteke se salje nekoj swing formi i ti lepo propagiras izuzetak do svoje forme i tamo uhvatis izuzetak i prikazes ovu lepu poruku, tako da korisnik zna sta se desilo.

Hmm...Ok, mislim da sam razumeo....thanks

zaboravio sam da kažem i čemu to. pa recimo zbog toga što je osim
logovanja izuzetka (koje ovde radiš) važno da ga propagiraš i
obavestiš pozivajuću metodu da se desio izuzetak i da i ona treba da
ga obradi. što ti je rekao augustus, možeš da ga propagiraš do GUI-ja
koji će prikazati adekvatnu poruku korisniku. na ovaj način recimo
možeš i da poboljšaš povratnu informaciju iz metode. pa umesto da
proveravaš povratnu vrednost, deklarišeš da ona proizvodi određene
tipove izuzetaka koje posle hvataš i obrađuješ.

na kraju krajeva možeš i da odbaciš izuzetak ako ne želiš da ga obradiš tako što ćeš npr deklarisati da metoda baca izuzetak, koja pozivu tu "rizičnu" metodu..evo možda malo jasnije

ono što će se desiti u slučuju da rizicnaMetoda() zaista baci izuzetak je to da će ona nestati sa stacka a izuzetak će biti bačen sledećoj metodi na stacku a to je pozivajuća metoda,u ovom slučaju foo() koja nema try/catch blok ali posto ona "baca" izuzetak ona nestaje sa stacka,a izuzetak se baca sledećoj metodi na stacku,ako je main sledeća i zadnja ona će ga samo odbaciti i tu je kraj

_{[Ovu poruku je menjao [REaS0n] dana 13.04.2008. u 12:11 GMT+1]}