Exceptions framför "manuell" felhantering?

Kommer ihåg att jag läste på MSDN för ett tag sen att try-catch var långsammare...

Istället för att köra try och catcha nullreferenceexception skulle man kolla ifall det var null innan. Detta var då ifall det skulle ske ofta problemet, och inte bara när något gått fel

Bäst är att inte göra fel. Kan det inte undvikas är det förmodligen klokt att ta hand om de enkla fallen och spara try/catch till oförutsägbara och sällsynta fel. Viss prestandaförsämring får man räkna med. Här har någon testat i c#: http://www.chinhdo.com/20080226/try-catch-blocks-performance/

Prestanda kommer i de flesta applikationer i andra hand när det gäller den här typen av problem. I modernare språk som C#, Java och Python t.ex., är det att föredra att kasta undantag om något går fel. En hyfsad förklaring till fördelen med undantag hittas här.

Sen ska man skilja på fel (Error) och undantag (Exception). Ett Error innebär i stort sett att något oförutsägbart och ohanterbart har inträffat, som inte går att återhämta sig från. Dessa ska med andra ord inte tas om hand av try/catch, då det inte går att reparera skadan. Exceptions ska man kunna förutse, t.ex. att en fil inte hittas, att man försöker läsa positioner i en array som inte finns, att man försöker göra om en icke-alphanumerisk sträng till siffror, o.s.v.

Man slipper även en massa if-satser för att se om ett objekt som returneras inte innehåller null (brukar tyvärr vara ett standardförfarande om något går fel i en metod som ska returnera ett objekt).

Jag föredrar med andra ord att hantera förutsägbara fel med Exceptions, och jag kan inte förstå varför man vill returnera felkoder och null-objekt istället. Men så utvecklar jag inte heller i C, så kanske är mitt inlägg helt överflödigt...

En relevant artikel:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xm...

Framförallt:

Förutsägbara fel kanske är fel(!) uttryck, men jag menar alltså i fall där man kan anta att ett undantag uppstår - t.ex. vid filläsning (kasta ett Exception upp i hierarkin om filen inte finns), nummerformatering av strängar (kasta ett Exception om strängen innehåller andra tecken än siffror), o.s.v.

Om du läste C++-länken som Psionicist gav bör du även läsa samma styleguide för Python. Som du ser skiljer det även mellan olika språk på hur man bör hantera undantag. Jag som hellre programmerar i Java är ju "uppfödd" med Exceptions, det kanske är därför jag förespråkar dem framför returkoder (jag står inte ut med alla if-satser helt enkelt!).

Om det blir svårare att integrera med de biblioteken för att man har stängt av exceptions ( som de skrev), måste det ju vara en fördel att HA exceptions?

Jag kör stenhårt på exceptions i C++; man slipper väldigt många checkar och koden blir snyggare och lättare. RAII utan exceptions kan ju inte vara så kul heller, vad ska man göra om en constructor misslyckas initiera objektet? Typ sätta en zombieflagga som måste checkas senare. Om man kastar ett exception i en constructor försvinner objektet som håller på att konstrueras vilket leder till att man endast kan ha fungerande objekt i omlopp.

Ingen idé att prata om prestandan direkt; den påverkas oftast bara när man throw:ar ett objekt vilket borde vara väldigt sällan/aldrig. Inte ens det behöver man bry sig om på dagens datorer. Det blir dock lite extra information i stackframesen, men det är lätt värt det -- man slipper ju alla if-check:ar!

En dålig sak med exceptions är att all kod måste vara kompilerad med exceptions aktiverade, om man försöker kasta ett exception genom ett tredjepartsbibliotek (typ från en callbackfunktion) som inte är kompilerat med exceptions i åtanke så har jag för mig att man hamnar i undefined behavior, om man har tur blir det en std::terminate.

1. RAII + exceptions + referenser istället för pekare = nice.
2. om du try...catch:ar överallt gör du fel

Det skulle fungera bra, har för mig att jag sett en del libs som faktiskt gör så.

Error codes har en till fördel över exceptions i C++; det är lättare att se vilka fel en funktion kan få. Det blir då lite lättare att utföra unit testing samt kanske lättare att få ett grepp om vad funktionen gör, vilket är hyffsast viktigt för ett bibliotek.

Försöker täcka alla baser här med både för- och nackdelar, men fördelarna väger lätt över så skönt att slippa all felhantering som förslummar koden.

Nja, en stor try-catch runt hela din kod är väl onödigt; obehandlade exceptions får väl programmet att avslutas "korrekt" ändå?

Man kan ju ha det om man vill visa en meddelanderuta för användaren eller nått. Man behöver inte; om ett exception går utanför main kallas std::terminate.

Try...catch bör sättas där man kan hantera felet på ett vettigt vis, t ex om en path misslyckas att initieras kan man försöka med en fallback eller nått sånt. Då är det extra viktigt att man städar upp saker i destructors.

En god tumregel för C++ är att exceptions ska användas om man också använder RAII. Annars inte.

Man bär vara lite förskiktig med exceptions i c++ i konstruktorer, eftersom om du kastar en exception från konstruktorn kommer destruktorn inte köras. En konstruerad klass är i cpp en klass där konstruktorn körts klar. Kan dock komma att formuleras om i C++0x så att det är färdigkonstruerad om _NÅGON_ konstruktor körts klart.

All stack-unwinding-kod kan dessutom ta mycket minne, så om man arbetar i en begränsad miljö kan det vara bra om man är försiktig.

Destruktorn kommer att köras på alla medlemsobjekt som hunnit konstrueras, bara för att göra det tydligt.