Kdaj uporabiti izjeme?

Razcepljeno iz [C++] Portabilna funkcija za kopiranje datotek.

Ja Shinobi, vse lepo in prav, ampak poanta izogibanja exceptionom (recimo v primeru file copy funkcije) je ta, da uporabniku take funkcije, kadar se ne sekira za njen rezultat, funkcije ni treba obkrožat s try catch blokom. Naprimer, hočeš nekaj spravit v en fajl, a bi rad ta fajl, če že slučajno obstaja backupiral. Tako enostavno kličeš fileCopy(fajl) in te ne brigajo posledice. Če fajl ne obstaja se bo funkcija tiho pritožila, program bo laufal dalje. Če se fajla ne da odpret se bo funkcija pritožila (ne bo naredila backupa), ti boš pa še vedno napako lahjko ujel ko boš hotel prepisat ta fajl. Itd. To da fajla ni bilo mogoče skopirat ni neka nevarna zadeva v rang napak pri alokaciji memoryja. Poleg tega pa se lahko funkcijo uporablja tako, da imaš vedno pripravljeno reakcijo na njen rezultat. Spet isti scenarij, le da tokrat pogledaš, backupa ni bilo mogoče narediti kljub temu, da fajl obstaja in o tem obvestiš uporabnika. Tudi ta scenarij ni primeren za exceptione.

Exceptioni niso za preverjanje rezultatov določenih funkcij. Uporabiš jih tam, kjer si želiš nek blok kode popolnoma varen. Tako varen, da če pride do česarkoli (predvsem sem sodijo neprevdidljivi ali redki dogodki) imaš pripravljeno neko reakcijo. Koda, ki te sili v uporabo try catch blokov samo zato, da preveriš rezultat funkcije je slaba koda.

Še en primer slabe uporabe exceptionov: Borland ima nek class AnsiString (Borland hoče njihov C++ naredit podoben Delphiju), ki ima funkcijo za pretvarjanje stringa v float. Vse lepo in prav, dokler ti ta funkcija ne vrže exceptiona, če se stringa ne da pretvoriti v float. In če potem hočeš narest nek uporaben GUI (kjer se seveda v vsakem widgetu skrivajo AnsiStringi), moraš hočeš nočeš vsako pretvarjanje text -> float opremit s try catch blokom. Madona, da uporabnik narobe vpiše float je tako totalno pričakovana zadeva, da exceptioni tu nimajo kaj iskat. Niti v Borlandovih najhujših nočnih morah ne. To je stvar za en if stavek. Bad bad Borland.

> Exception, kot pove ime, se uporablja ko pride do izjemne napake, ki jo mora razhroščiti in odpraviti programer. Ne uporabljajo se za napake, ki se skoraj zagotovo pojavijo med uporabo programa oz. so pričakovane.

Jaz gledam na exceptione bolj kot na se eno orodje, da v dolocenih primerih kodo naredis elegantnejso/krajso. Se mi zdi popolnoma smiselno za operacije nad fajli uporabljati exceptione, ce so recimo del vecje transakcije.

Uf, so vam pa resno všeč teli exceptioni Sicer mi je prav žal, da se je tale tema malo izrodila v to smer, ampak očitno vas je treba še kakšno malenkost naučit.

Ja Kopernik, saj se mora tako ali tako vedno klicatelj funkcije odločiti kaj bo storil v primeru neprietne situacije, pa naj ta funkcija meče exceptione kot nora ali pa ne.

/* takole ... */
try {
   copyFile("a", "b");
} catch (...) {
   cout << "warning: copy failed";
}
/* ali takole ... */
if (copyFile("a", "b") != Copy_Ok) {
   cout << "warning: copy failed";
}

To je v primeru, da veš kaj storiti, če ti funkcija faila (razlog za fail ti ni pomemben). Spodaj pa v primeru, da se ti fučka ali funkcija uspe ali ne:

/* takole ... */
try {
   copyFile("a", "b");
} catch (copyFileEsception) {
   // guard copy file failures although we do not care about them
} catch (...) {
   // pass through non-kiddie stuff
   throw;
}
/* ali takole ... */
copyFile("a", "b"); 
// no need to check for copy file failures as they are irrelevant

Kaj je bolj elegantno, kaj je bolj pregledno, kaj je bolj varno, kaj je hitrejše in kaj je bolj pravilno? Če ti bo nek drug programer gledal kodo z exceptioni si bo mislil: "Zlomka, kakšen voodoo dela tale copyFile, da ga je treba zavarovat s try catch blokom?"

Zdej pa še enkrat vsi skupaj: Exceptioni so namenjeni izjemnim situacijam, ne handlanju običajnih potekov programa!
Ne uporabljat exceptionov tam, kjer za isto stvar obstajajo drugi (in niti ne bolj komplicirani) prijemi. Enostavno NE!

P.S. Kopernik, a misliš da bi bilo Borlandu res tako težko napisat funkcijo bool AnsiString::toFloat(float& f) const namesto float AnsiString::toFloat() const?

P.S. Kopernik, a misliš da bi bilo Borlandu res tako težko napisat funkcijo bool AnsiString::toFloat(float& f) const namesto float AnsiString::toFloat() const?

To bi bilo pa skrajno neintuitivno in tak API bi bil zgled, kako se funkcij NE poimenuje. Mislim, toFloat(), ki vrne boolean. Kvečjemu canConvert() ... drugače pa sem že zgoraj rekel, napaka ali rezultat, ko sem repliciral na to, da se funkcija sama odloči kaj storiti v primeru nezmožnosti kopiranja.

Jaz gledam na exceptione bolj kot na se eno orodje, da v dolocenih primerih kodo naredis elegantnejso/krajso. Se mi zdi popolnoma smiselno za operacije nad fajli uporabljati exceptione, ce so recimo del vecje transakcije.
Sem sicer odprt za diskusijo, kje gre za pravilno uporabo izjem in kje gre za abuse, vendar sem svoje pravilo palca že navedel (zdaj že več kot enkrat). Lahko prediskutiramo error handling v širšem kontekstu če odpremo drugo temo.

Kar si podal za prvi primer je v bistvu popolnoma isto, samo da namesto if uporabiš try ... catch.
Ne popolnoma. Prvič manjši overhead, drugič možnost ignoriranja napake pri čemer se code flow nadaljuje v klicatelju copyFile (ne da bi ga obdajal v try catch pri vsakem klicu posebej). Če je tvoj cilj prenesti handlanje napake v katero od parent funkcij (se pravi prekiniti normalni flow programa in ga prenesti v catch), potem lahko pa še vedno v klicatelju copyFile vržeš izjemo.
Moja poanta pa je ravno v tem, da želiš prenesti code flow v catch le, ko pride do nepričakovane napake.
BTW: Kakor se spomnim RuntimeError še vedno "zmoti" normalni flow programa. Je preprosto exception, ki ga poznamo v C++, oz. ne zahteva eksplicitne deklaracije.

Res je tisto da funkcija sama shandla napako je slaba ideja. Moj kiks.

Še stara tema Coding Style.

Ah ja, da me ne bo kdo razumel kot exception fanatika. Kadar programiram gui kodo v qt ali wxwidgets sploh ne uporabljam izjem, ker je itak vecino kode v raznih callback handlerjih (= slotih), tam pa izjeme ne delujejo ravno najbolje. Pa se prevedes s -fno-exception pa je binary na koncu se toliko manjsi.

Ne, exception ni dokoncen, ampak je koda "transakcijska", torej imas 10 nivojev ali vec, in vse akcije na vseh nivojih morajo uspeti. Potem se pa kot zadnja akcija izvede nekam zapis o uspehu. Try/catch je pa samo en in to cisto na vrhu transakcije, ki v catchu rece "transakcija ni uspela". Najlazje je, da kar vse akcije sprozijo izjemo, ko gre karkoli narobe, kot pa da notri mesas if-e.

Tisto s throw freeze sem pa pocel v c++-su. V javi bi verjetno lahko vklopil green-threads...

Exceptioni so, ce se jih uporablja premisljeno, se kar uporabno orodje.Pri pretirani uporabi pa koda postane spaghetti, ravno tako kot pri (pretirani) uporabi goto.
Npr. koda , v kateri se exception lovi, kot je v zadnjem postu napisal 64202, sele na cisto na koncu stacka, je zaradi uporabe exceptionov preglednejsa.
Ce pa bos za vsako funkcijo (ki je znotraj zakljucena celota, morda celo implementirana v kaksni loceni knjiznici) pisal try-catch blok, pa se z vidika preglednosti bolj splaca, da enostavno evaluiras error kodo, ki jo funkcija vrne.

Videl sem pa tudi ze kodo, ko so ljudje iz loopov skakali tako z goto-ji kot z exceptioni. Oboje je (vsaj za moj okus) strasno grdo. In nevarno.

In mnogo dodatnih tezav nastopi pri multithreaded programih.

V embedded programski opremi pa exceptioni v principu prav ne pridejo, ker tam nepredvidenih situacij NE SME BITI, ker jih moramo poloviti ze z assertioni med razvojem programske opreme; za resevanje nepredvidenih situacij uporabljamo druge mehanizme (good old watchdog timer etc.).

Bom še jaz postavil eno konkretno vprašanje. Sicer ne zadeva ne c++ in ne jave, ampak PHP. Primer funkcije:

public function __construct ($configuration) {
	if (!is_array ($configuration)) {
		throw new Exception ('$Configuration parameter must be array.');
	}
	if (!$this -> validateConfigurationSchema ($configuration, $this -> configurationSchema)) {
		throw new Exception ('Given configuration does not validate configuration schema.');
	}
	$this -> connect ($configuration);	
}

Ali je to dober način (z uporabo exceptionov)? Konkretna funkcija je iz razreda, ki se uporablja za delo z zbirkami podatkov. Parameter, ki je podan, mora biti polje in mora imeti določene ključe v polju (ključi se preverijo s funkcijo validateConfigurationSchema()). Ali sploh obstaja kakšen drugi način (v PHP-ju), s katerim bi preveril ali podani parametri ustrezajo določenemu tipu podatkov? Ker ko moraš funkciji podati tri parametre, nastane kar velik šmorn, če preverjaš vsak parameter.

Ja uporabnosti ne gre preveč trejdat za lepo kodo. Ampak za večino probemov obstaja elegantna rešitev (ne bom trdil da za tvojega tudi). Če pa že ne, je pa povsem sprejemljivo uporabit eno zelo grdo kodo, jo zapakirat v knjižnico, jo dodobra pretestirat in vse, njeno uporabo pa naredit elegantno. V najboljših knjižnicah je najbolj ogabna koda. In prav je tako. Knjižnice naj so tisto, kar skrije grde stvari a kar naj čimbolj učinkovito dela in naj ponuja uporabniku čim bolj enostavno uporabo.