---

Hej :)

Jeg sidder og roder med at få noget exception handling til at køre, og
det vil ikke som jeg vil. Jeg vil lige advare om at jeg ALDRIG har
rodet med den slags i C++ før (har dog 100% check på det i Delphi).

Jeg har noget som simpelt kan skrives som


#include <iostream>
#include <exception>

using namespace std;

void Test()
{
int a = 10;
int b = 3;
int c = a/(b-3); // division by 0 fejl her.
}

int main()
{
try
{
Test();
}
catch (exception &e)
{
cout << "Exception thrown! " << e.show() << endl;
}

return 0;
}

Programmet returnerer en "division by zero" fejl, men kalder ikke min
handler :(

Hvad gør jeg forkert?

---

Nicolai Hansen wrote:
> int c = a/(b-3); // division by 0 fejl her.

Division med 0 giver undefined behavior. Du kan ikke regne med noget som
helst. Måske får du en exception, måske går computeren ned og måske sker
der noget helt tredje.

Ivan Johansen

---

Ivan Johansen <NG5@Padowan.remove.dk> wrote in message news:<40053f96$0$95072$edfadb0f@dread11.news.tele.dk>...
> Nicolai Hansen wrote:
> > int c = a/(b-3); // division by 0 fejl her.
>
> Division med 0 giver undefined behavior. Du kan ikke regne med noget som
> helst. Måske får du en exception, måske går computeren ned og måske sker
> der noget helt tredje.

Hmm.. ok

det jeg har lavet vil altså virke hvis der istedet var tale om en NULL
pointer exception?

det var såmæn bare nemmere at teste med div/0 hehe; det skal bruges
til at debugge med for at undgå at programmet går ned

---

Nicolai Hansen wrote:
> Hmm.. ok
>
> det jeg har lavet vil altså virke hvis der istedet var tale om en NULL
> pointer exception?

Nej, der er ikke noget der hedder NULL pointer exception. At dereferere
en NULL pointer giver også udefineret adfærd.

Prøv med følgende kode:
#include <iostream>
#include <exception>

using namespace std;

void Test()
{
throw runtime_error("Error");
}

int main()
{
try
{
Test();
}
catch (exception &e)
{
cout << "Exception thrown! " << e.what() << endl;
}

return 0;
}

Her smider Test() en exception som bliver fanget i main(). Du skal være
opmærksom på at ikke alle exceptions nedarver fra std::exception. En
hvilken som helst type kan bruges som exception. Alle exceptions kan
fanges med catch(...)

Ivan Johansen

---

> Nej, der er ikke noget der hedder NULL pointer exception. At dereferere
> en NULL pointer giver også udefineret adfærd.

Hmm.. Jeg kender jo kun det her fra Delphi Og den kan fange alle
disse runtime errors også. Nu leger jeg jo så på linux hér, men
Windows Kernel kalder disse div/0 NULptr exceptions; og Delphi fanger
dem.

> Prøv med følgende kode:
> #include <iostream>
> #include <exception>
>
> using namespace std;
>
> void Test()
> {
> throw runtime_error("Error");
> }
>
> int main()
> {
> try
> {
> Test();
> }
> catch (exception &e)
> {
> cout << "Exception thrown! " << e.what() << endl;
> }
>
> return 0;
> }
>
> Her smider Test() en exception som bliver fanget i main(). Du skal være
> opmærksom på at ikke alle exceptions nedarver fra std::exception. En
> hvilken som helst type kan bruges som exception. Alle exceptions kan
> fanges med catch(...)
>
> Ivan Johansen

Det vil jeg lige prøve og se om jeg kan få selvtilliden tilbage ;)
Jeg havde dog håbet på at det kunne opfange runtime errors og smide
alle fejlene ned i en bug fil istedet for at crashe programmet...
Er det på nogen måde muligt? (her tænker jeg stadig på ting som NULptr
og div 0 fejl).

---

Nicolai Hansen wrote:
> Hmm.. Jeg kender jo kun det her fra Delphi Og den kan fange alle
> disse runtime errors også. Nu leger jeg jo så på linux hér, men
> Windows Kernel kalder disse div/0 NULptr exceptions; og Delphi fanger
> dem.

C++ er ikke Delhi. Selvom der er mangle ligheder er der endnu flere
forskelle.

> Det vil jeg lige prøve og se om jeg kan få selvtilliden tilbage ;)
> Jeg havde dog håbet på at det kunne opfange runtime errors og smide
> alle fejlene ned i en bug fil istedet for at crashe programmet...
> Er det på nogen måde muligt? (her tænker jeg stadig på ting som NULptr
> og div 0 fejl).

Sproget C++ garanterer intet om hvordan division med 0 og dereferering
af NULL pointer skal håndteres. Det vil derfor afhænge af din compiler
og operativsystem. Hvad gcc gør under Linux ved jeg ikke, men jeg kunne
forestille mig et eller andet signal fra operativsystemet. Hvordan dette
håndteres er jeg ikke helt klar over.

Ivan Johansen

---

Ivan Johansen wrote:

> Sproget C++ garanterer intet om hvordan division med 0 og dereferering
> af NULL pointer skal håndteres. Det vil derfor afhænge af din compiler
> og operativsystem. Hvad gcc gør under Linux ved jeg ikke, men jeg
> kunne forestille mig et eller andet signal fra operativsystemet.
> Hvordan dette håndteres er jeg ikke helt klar over.

Siden man ikke må skrive til eller læse fra NULL, så sendes der et
SIGSEGV (Segmentation fault) signal. Standard behandlingen af dette
signal er at lave en core dump (hvis ulimit tillader det) og afslutte
programmet. Med 'signal' funktionen kan du lave en alternativ handler,
men programmet kan så vidt jeg kan se ikke få lov til at fortsætte.
Signalet bliver gentaget indtil programmet afsluttes, så der er ikke
meget at bruge en speciel handler til. Man kan desuden ikke ignorere
SIGSEGV signalet.

--
PeKaJe

I Know A Joke!!

---

> Siden man ikke må skrive til eller læse fra NULL, så sendes der et
> SIGSEGV (Segmentation fault) signal. Standard behandlingen af dette
> signal er at lave en core dump (hvis ulimit tillader det) og afslutte
> programmet. Med 'signal' funktionen kan du lave en alternativ handler,
> men programmet kan så vidt jeg kan se ikke få lov til at fortsætte.
> Signalet bliver gentaget indtil programmet afsluttes, så der er ikke
> meget at bruge en speciel handler til. Man kan desuden ikke ignorere
> SIGSEGV signalet.

OK - ret klar tale. Så må jeg finde på en anden måde at gøre dette på :)

---

Peter Jensen wrote:
> Ivan Johansen wrote:
>
>>Sproget C++ garanterer intet om hvordan division med 0 og dereferering
>>af NULL pointer skal håndteres. Det vil derfor afhænge af din compiler
>>og operativsystem. Hvad gcc gør under Linux ved jeg ikke, men jeg
>>kunne forestille mig et eller andet signal fra operativsystemet.

Det er korrekt.

> Siden man ikke må skrive til eller læse fra NULL, så sendes der et
> SIGSEGV (Segmentation fault) signal. Standard behandlingen af dette
> signal er at lave en core dump (hvis ulimit tillader det) og afslutte
> programmet. Med 'signal' funktionen kan du lave en alternativ handler,
> men programmet kan så vidt jeg kan se ikke få lov til at fortsætte.

Jo, det kan det godt få lov til. Man skal bare passe på med at returnere
fra signalhandleren således at det som har udløst fejlen, ikke gentages.

> Man kan desuden ikke ignorere SIGSEGV signalet.

Det ville være uklogt at gøre det, men man kan vel godt.

Advarsel: Det følgende program er et yderst uportabelt
Linux/x86-program. Det bruger funktioner mv. som ikke kendes i standard
C, og indeholder adskillige tilfælde af udefineret adfærd i henhold til
standard C. Endvidere kaldes funktioner fra signal-handleren som man
under normale omstændigheder ikke må kalde fra en signal-handler. Man
bør studere dokumentationen grundigt før noget lignende bruges i praksis!

#include <signal.h>
#include <setjmp.h>
#include <stdio.h>

jmp_buf env;
int where;

void sighandler (int sig, siginfo_t *info, void *p)
{
if (sig == SIGFPE && info->si_code == FPE_INTDIV)
puts ("Integer divide by zero");
else if (sig == SIGSEGV && info->si_code == SEGV_MAPERR)
puts ("Address not mapped to object");
else
puts ("Some other error");
longjmp (env, ++where);
}

int divide_by (int i)int main ()
{
puts ("Start");
struct sigaction sa;
sa.sa_sigaction = sighandler;
sigaction (SIGFPE, &sa, 0);
sigaction (SIGSEGV, &sa, 0);
switch (setjmp (env))
{
case 0:
divide_by (0);
break;

case 1:
reference (0);
break;
}
puts ("End");
}

Når jeg kører det, får jeg:
$ ./a.out
Start
Integer divide by zero
Address not mapped to object
End
$

---

Byrial Jensen wrote:

>> Siden man ikke må skrive til eller læse fra NULL, så sendes der et
>> SIGSEGV (Segmentation fault) signal. Standard behandlingen af dette
>> signal er at lave en core dump (hvis ulimit tillader det) og afslutte
>> programmet. Med 'signal' funktionen kan du lave en alternativ
>> handler, men programmet kan så vidt jeg kan se ikke få lov til at
>> fortsætte.
>
> Jo, det kan det godt få lov til. Man skal bare passe på med at
> returnere fra signalhandleren således at det som har udløst fejlen,
> ikke gentages.

OK, men det bliver vist ikke pænt ...

>> Man kan desuden ikke ignorere SIGSEGV signalet.
>
> Det ville være uklogt at gøre det, men man kan vel godt.

Det jeg mente var at hvis man sætter signal handler til SIG_IGN
(ignore), så siger POSIX at resultatet er udefineret. På mit Linux
system opfører den sig som om SIG_DFL (default handler) var aktiv, med
andre ord en core dump og afslutning. Det ville jeg så ikke kalde at
ignorere signalet.

> Advarsel: Det følgende program er et yderst uportabelt
> Linux/x86-program. Det bruger funktioner mv. som ikke kendes i
> standard C, og indeholder adskillige tilfælde af udefineret adfærd i
> henhold til standard C. Endvidere kaldes funktioner fra
> signal-handleren som man under normale omstændigheder ikke må kalde
> fra en signal-handler. Man bør studere dokumentationen grundigt før
> noget lignende bruges i praksis!

[Snip - programkode og output]

Eeeew! Godt nok er setjmp og longjmp specificeret af POSIX, men det
giver noget grim kode. Det er næsten værre end goto, da denne i det
mindste har begrænset scope. Med longjmp kan du i princippet hoppe alle
steder hen hvor du har været før. Spaghetti ...

Under alle omstændigheder mener jeg ikke at der er nogen logisk grund
til at fange en SIGSEGV, da dette signal kun burde modtages når
programmøren har dummet sig (når hardwaren altså virker optimalt). I så
fald vil en core dump hjælpe meget mere.

--
PeKaJe

Who wouldn't be interested in everything we do?! -- Calvin

---

Den 15 Jan 2004 21:32:45 GMT skrev Peter Jensen:
>> Advarsel: Det følgende program er et yderst uportabelt
>> Linux/x86-program. Det bruger funktioner mv. som ikke kendes i
>> standard C, og indeholder adskillige tilfælde af udefineret adfærd i
>> henhold til standard C. Endvidere kaldes funktioner fra
>> signal-handleren som man under normale omstændigheder ikke må kalde
>> fra en signal-handler. Man bør studere dokumentationen grundigt før
>> noget lignende bruges i praksis!
>
>[Snip - programkode og output]
>
>Eeeew! Godt nok er setjmp og longjmp specificeret af POSIX, men det
>giver noget grim kode. Det er næsten værre end goto, da denne i det
>mindste har begrænset scope. Med longjmp kan du i princippet hoppe alle
>steder hen hvor du har været før. Spaghetti ...

C-udgaven af trow/catch. Ikke helt så pæn at skrive, men samme
fuktionalitet.

Throw kan også hoppe ud af 17 funktioner, helt tilbage til main.

>Under alle omstændigheder mener jeg ikke at der er nogen logisk grund
>til at fange en SIGSEGV, da dette signal kun burde modtages når
>programmøren har dummet sig (når hardwaren altså virker optimalt). I så
>fald vil en core dump hjælpe meget mere.

Prøv at bruge /bin/vi - når den modtager SIGSEGV (jo, jeg har været ude
for det engang), så gemmer den lige den fil man var ved at rette i en
temp-fil, så man kan få sine ændringer frem igen.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:

>> Eeeew! Godt nok er setjmp og longjmp specificeret af POSIX, men det
>> giver noget grim kode. Det er næsten værre end goto, da denne i det
>> mindste har begrænset scope. Med longjmp kan du i princippet hoppe
>> alle steder hen hvor du har været før. Spaghetti ...
>
> C-udgaven af trow/catch. Ikke helt så pæn at skrive, men samme
> fuktionalitet.
>
> Throw kan også hoppe ud af 17 funktioner, helt tilbage til main.

Jeg har ikke undersøgt det præcist, men jeg har på fornemmelsen at man
kan lave en del mere skade med *jmp funktionerne end man kan med
throw/catch. C++ metoden virker mere struktureret. Der hopper man kun
én vej (med mindre der er noget jeg har glemt). Med C metoden er der
tilsyneladende intet (ud over god programmering) som forhindrer at man
hopper til en tilfældig funktion som man engang har kaldt og gemt status
i. Muligheden for at lave seriøs spaghetti kode er tilstede.

>> Under alle omstændigheder mener jeg ikke at der er nogen logisk grund
>> til at fange en SIGSEGV, da dette signal kun burde modtages når
>> programmøren har dummet sig (når hardwaren altså virker optimalt). I
>> så fald vil en core dump hjælpe meget mere.
>
> Prøv at bruge /bin/vi - når den modtager SIGSEGV (jo, jeg har været
> ude for det engang), så gemmer den lige den fil man var ved at rette i
> en temp-fil, så man kan få sine ændringer frem igen.

Har lige undersøgt sagen. Det ser ud som om at vim lige kalder den
funktion som jævnligt gemmer dens swap fil, når SIGSEGV modtages. Det
er teoretisk set en farlig løsning, da ingen data kan antages at være
sikre. Jeg tror dog på at der er taget højde for det på en eller anden
smart måde. Generelt er det meget sjældent at man mister data med vim.
Jeg har oplevet at strømmen er gået midt i en sætning jeg var ved at
skrive, og da jeg startede den op igen manglede der kun få bogstaver.

--
PeKaJe

Crashing is violent; that's why there are more violent games for Windows
- and they'll always work. -- Ewout Stam

---

Den 15 Jan 2004 23:12:25 GMT skrev Peter Jensen:
>Kent Friis wrote:
>
>>> Eeeew! Godt nok er setjmp og longjmp specificeret af POSIX, men det
>>> giver noget grim kode. Det er næsten værre end goto, da denne i det
>>> mindste har begrænset scope. Med longjmp kan du i princippet hoppe
>>> alle steder hen hvor du har været før. Spaghetti ...
>>
>> C-udgaven af trow/catch. Ikke helt så pæn at skrive, men samme
>> fuktionalitet.
>>
>> Throw kan også hoppe ud af 17 funktioner, helt tilbage til main.
>
>Jeg har ikke undersøgt det præcist, men jeg har på fornemmelsen at man
>kan lave en del mere skade med *jmp funktionerne end man kan med
>throw/catch.

Det kan man sagtens, for i C holder compileren generelt ikke styr på
noget som helst.

>C++ metoden virker mere struktureret. Der hopper man kun
>én vej (med mindre der er noget jeg har glemt). Med C metoden er der
>tilsyneladende intet (ud over god programmering) som forhindrer at man
>hopper til en tilfældig funktion som man engang har kaldt og gemt status
>i. Muligheden for at lave seriøs spaghetti kode er tilstede.

Man kan godt forsøge, men resultatet er udefineret, fordi stakken
ikke længere indeholder det den gjorde dengang.

Det er kun "tilladt" at hoppe ud af en funktion, ikke ind.

>>> Under alle omstændigheder mener jeg ikke at der er nogen logisk grund
>>> til at fange en SIGSEGV, da dette signal kun burde modtages når
>>> programmøren har dummet sig (når hardwaren altså virker optimalt). I
>>> så fald vil en core dump hjælpe meget mere.
>>
>> Prøv at bruge /bin/vi - når den modtager SIGSEGV (jo, jeg har været
>> ude for det engang), så gemmer den lige den fil man var ved at rette i
>> en temp-fil, så man kan få sine ændringer frem igen.
>
>Har lige undersøgt sagen. Det ser ud som om at vim lige kalder den
>funktion som jævnligt gemmer dens swap fil, når SIGSEGV modtages. Det
>er teoretisk set en farlig løsning, da ingen data kan antages at være
>sikre.

Det er derfor det gemmes i en ny fil. Hvis noget går galt, er man
altså ikke værre stillet end at man stadig har mistet de data, man
alligevel ville have mistet hvis den ikke forsøgte at gemme.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Under alle omstændigheder mener jeg ikke at der er nogen logisk grund
> til at fange en SIGSEGV, da dette signal kun burde modtages når
> programmøren har dummet sig (når hardwaren altså virker optimalt). I så
> fald vil en core dump hjælpe meget mere.

Jo... jeg har en lille server som kan forstå nogle telnet kommandoer.
Disse bliver fundet i en ret stor tabel, som også indeholder hvilken
funktion kommandoen skal udføre. Der er flere end mig der programmerer
på dette her projekt; der er sikkert mange af funktionerne som har
muligheder for fejl.
Mit mål var at når en bruger skrev "foo" i sin telnet og serveren
kaldte CommandFoo(), som der så var en crash-bug i, blev det logget
til en fil (+brugeren fik det at vide), samtidigt med at "foo"
kommandoen blev disablet.

På denne måde var det håbet at vi kunne rette fejlene uden konstante
reboots/genstart pga crash. Rent dovenskab ;)

Desværre er jeg lidt nervøs for at det kode der blev givet vil give
flere fejl end alle mine kommandoer tilsammen hehe .. men det er da
måske værd at prøve :)

Samtidig skal der da herfra lyde en lille opfordring (pip pip) til C++
folkene til at kigge lidt på Borland's (Delphi's) exception handling,
og måske udvide deres til noget der ligner lidt ... er lidt bange for
at sige "noget som er ligeså godt" - for Delphi's exception handling
er nok egentligt ikke "god" (den opfordrer lidt til at smide
diskutabel kode ind i en try/except og så glemme alt om range
checking) ... måske "noget som er ligeså omfattende" vil være bedre :)

---

Byrial Jensen wrote:
> Advarsel: Det følgende program er et yderst uportabelt
> Linux/x86-program. Det bruger funktioner mv. som ikke kendes i standard
> C, og indeholder adskillige tilfælde af udefineret adfærd i henhold til
> standard C. Endvidere kaldes funktioner fra signal-handleren som man
> under normale omstændigheder ikke må kalde fra en signal-handler. Man
> bør studere dokumentationen grundigt før noget lignende bruges i praksis!

Hovsa, jeg fik ikke kopieret programmet jeg havde skrevet, korrekt. Jeg
prøver lige igen.

#include <signal.h>
#include <setjmp.h>
#include <stdio.h>

jmp_buf env;
int where;

void sighandler (int sig, siginfo_t *info, void *p)
{
if (sig == SIGFPE && info->si_code == FPE_INTDIV)
puts ("Integer divide by zero");
else if (sig == SIGSEGV && info->si_code == SEGV_MAPERR)
puts ("Address not mapped to object");
else
puts ("Some other error");
longjmp (env, ++where);
}

int divide_by (int i)
{
return 1 / i;
}

int reference (int *p)
{
return *p;
}

int main ()
{
puts ("Start");
struct sigaction sa;
sa.sa_sigaction = sighandler;
sigaction (SIGFPE, &sa, 0);
sigaction (SIGSEGV, &sa, 0);
switch (setjmp (env))
{
case 0:
divide_by (0);
break;

case 1:
reference (0);
break;
}
puts ("End");
}

> Når jeg kører det, får jeg:
> $ ./a.out
> Start
> Integer divide by zero
> Address not mapped to object
> End
> $

Jeg skrev programmet i C i modsætning til C++ fordi ingen af de ting jeg
bruger mht. signaler, er C++-specifikke. Jeg bruger longjmp() til at
forlade signal-handleren for at undgå at returnere til den fejlende
kode. Det skulle være sikkert i det her tilfælde.

Det ikke rigtigt at man kan returnere til et hvilket som helst sted i
koden hvor man har været før, med longjmp(). Man returnerer dertil hvor
det tilsvarende setjmp() returnede, og den funktion som setjmp() er i,
må ikke selv have returneret. Endvidere må man ikke have forladt blokke
som erklærer evt. arrays med variabel længde. Det er op til programmøren
at sørge for at disse begrænsninger er overholdt hvis man vil undgå
udefineret adfærd på grund af longjmp()-kaldet. Og nej, jeg påstår ikke
at setjmp/longjmp er pænt. Kun at de i visse sjældne situationer er
nødvendige eller praktiske.

---

> Jeg sidder og roder med at få noget exception handling til at køre, og
> det vil ikke som jeg vil. Jeg vil lige advare om at jeg ALDRIG har
> rodet med den slags i C++ før (har dog 100% check på det i Delphi).

<snip kode>

> Programmet returnerer en "division by zero" fejl, men kalder ikke min
handler :(

Du taler om delphi, så måske du bruger c++ builder?
Så kan det være at du bare har glemt at slå builders egen exception break
fra.
tools/debugger options/stop on c++ exceptions
slå den fra. Jeg mindes en gang for lang tid siden at have bøvl med at mine
exception handlers tilsyneladende ikke blev kaldt.

---

"Georg Bagen Busk" <no.mail@no.no> wrote in message news:<bu5g3e$ubg$1@news.cybercity.dk>...
> > Jeg sidder og roder med at få noget exception handling til at køre, og
> > det vil ikke som jeg vil. Jeg vil lige advare om at jeg ALDRIG har
> > rodet med den slags i C++ før (har dog 100% check på det i Delphi).
>
> <snip kode>
>
> > Programmet returnerer en "division by zero" fejl, men kalder ikke min
> handler :(
>
> Du taler om delphi, så måske du bruger c++ builder?
> Så kan det være at du bare har glemt at slå builders egen exception break
> fra.
> tools/debugger options/stop on c++ exceptions
> slå den fra. Jeg mindes en gang for lang tid siden at have bøvl med at mine
> exception handlers tilsyneladende ikke blev kaldt.

Nej, jeg bruger gcc på linux :)