---

Hej,

Jeg har set, at man i C++ kan og bør(?) angive, hvis éns funktioner
risikerer at smide en exception:

void unsafe_op(double) throw (std::out_of_range);

Hvorfor er det godt at gøre det, ud over den dokumentations-gevinst, som
funktionsprototypen da får?

Hvis man nu har en funktion - lad os kalde den indirect(), der kalder
unsafe_op-funktionen, skal indirect() da også erklære, at den kan
risikere at smide en std::out_of_range, hvis indirect() ikke selv
håndterer exception'en? (Jeg går ud fra, at svaret er ja, men
Stroustrups bog skriver ikke særlig konkret om dette emne, synes jeg.)

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote in:

[8<8<8<]
> Jeg har set, at man i C++ kan og bør(?) angive, hvis éns funktioner
> risikerer at smide en exception:
>
> void unsafe_op(double) throw (std::out_of_range);
>
> Hvorfor er det godt at gøre det, ud over den dokumentations-gevinst, som
> funktionsprototypen da får?

Der er 3 væsentlige scenarier:
void foo_1();
void foo_2() throw();
void foo_3() throw (bar);

foo_1 kan smide en hvilken som helst exception.

foo_2 kan ikke smide nogen exception overhovedet.
Det er væsentligt for at kunne skrive exception sikker kode i C++.
Hvis det alligevel skulle ske at en exception prøver at komme ud, vil
programmet terminere.

foo_3 kan kun lade de nævnte exception typer (eller nedarvede) komme ud af
funktionen.
Det er nok den mindst nyttige form.
Hvis det alligevel skulle ske at en exception af en anden type prøver at
komme ud, vil programmet terminere.

I relation til exception håndtering, og det at skrive exception sikker kode,
er det væsentligste:
* Kan der komme en exception
* Er der smidt en exception
og i mindre udstrækning, hvilken type exception blev smidt.

Det at vide hvad exception sikker kode er og hvordan man skriver det er
væsenligt.
Gode kilder til det er:
The C++ Programming Language, Special Edition (alternativt Third Edition)
Bjarne Stroustrup
ISBN 0-201-70073-5 (Third: 0-201-88954-4)
Appendix E, som også kan downloades fra Bjarne Stroustrup's hjemmeside
(http://www.research.att.com/~bs/)

Exceptional C++
Herb Sutter
ISBN 0-201-61562-2

More Exceptional C++
Herb Sutter
ISBN 0-201-70434-X

>
> Hvis man nu har en funktion - lad os kalde den indirect(), der kalder
> unsafe_op-funktionen, skal indirect() da også erklære, at den kan
> risikere at smide en std::out_of_range, hvis indirect() ikke selv
> håndterer exception'en? (Jeg går ud fra, at svaret er ja, men
> Stroustrups bog skriver ikke særlig konkret om dette emne, synes jeg.)

Nej.
C# har valgt en tilsvarende løsning.
Java skal liste alle de mulige exceptions, inklusive dem som kaldte
funktioner kan smide, og som den ikke håndterer.


Venlig hilsen

Mogens Hansen

---

Troels Arvin wrote:
> void unsafe_op(double) throw (std::out_of_range);
>
> Hvorfor er det godt at gøre det, ud over den dokumentations-gevinst, som
> funktionsprototypen da får?

Som Mogens siger er det interessante ikke hvad en funktion kan smide af
exceptions, men om den smider exceptions. Et problem ved at angive hvad
en funktionen kan smide af exceptions er at du derved giver en garanti
over for den som bruger funktionen. Det kan derfor være et problem at
tilføje flere exceptions til listen senere, da den som kalder din
funktion måske ikke forventer denne tilføjelse.

Compileren vil ikke forhindre dig i at smide exceptions du ikke har
specificeret. I stedet vil den under kørslen tjekke at kun tilladte
exceptions undslipper og ellers afbryde programmet. Du får derved et
overhead i funktionen og denne kontrol kan næppe bruges til noget.

I praksis mener jeg heller ikke at en tom throw() specifikation, som
angiver at ingen exceptions undslipper kan bruges til andet end
dokumentation. Jeg plejer derfor at skrive det som en kommentar:
void SafeFunktion(double); //throw()

Så giver det ikke noget overhead og den som kalder funktionen kan stadig
se at den ikke smider nogen exceptions.

Ivan Johansen