3. Errorcodes

Errorcodes

  • H

    Nexus schrieb:

    hartmut1164 schrieb:

    Wenn bei den heutigen Systemen kein Heap zu allocieren ist, dann lief etwas sehr uebel

    Wieso? std::bad_alloc wird zum Beispiel auch geworfen, wenn kein genügend grosser Speicherbereich an einem Stück gefunden werden kann.

    Und das heisst, dass das Programm (oder sonst etwas) sehr schlimmes ablaeuft. Das letzte Mal, dass ich einen fragmentieren Heap sah war auf Win3.11 (muss baer sagen, dass ich seit WIN NT4 vor keiner Win-Kiste mehr sass).

    0
  • H

    Dravere schrieb:

    hartmut1164 schrieb:

    Mmmhh ... Jein. abort () ist soetwas wie das Zeichen fuer es ging richtig schief. Wenn bei den heutigen Systemen kein Heap zu allocieren ist, dann lief etwas sehr uebel und es ist IMHO dann besser, die Sache so brutal als moeglich abzuwuergen. Eine Datenbank sollte mit einem toten Client zurechtkommen, und auch ein noch offener File ist fuer ein Betriebssystem heute kein wirkliches Problem mehr sein - schliesslich entspricht abort () etwa dem Verhalten von SIGKILL und damit muss das Betriebssystem/Datenbanken etc. auch umgehen koennen.

    Die Exception bad_alloc durchwerfen lassen, so hast du einen brutalen Absturz, aber das Programm räumt alles auf. abort und exit haben in C++ eher nichts zu suchen.

    Ich weiss aber nicht wo der Absturz war. Bei abort () habe ich wenigstens einen core-File und kann nachsehen wo es passiert ist. Gerade dieses "Aufraeumen" vernichtet ja diese wichtige Information.

    Wie gesagt: abort () sollte reserviert sei fuer schlimme Dinge und nicht fuer "normale" Fehler.

    0
  • Administrator

    hartmut1164 schrieb:

    Ich weiss aber nicht wo der Absturz war. Bei abort () habe ich wenigstens einen core-File und kann nachsehen wo es passiert ist. Gerade dieses "Aufraeumen" vernichtet ja diese wichtige Information.

    int *aGanzGross = NULL;
try
{
   aGanzGross= new int [1000000];
}
catch (bad_alloc&)
{
   cerr << "Autsch" << endl;
   // Etwas ins Log speichern.
   // Nun kannst du eine weitere Exception werfen oder...
   throw; // <- Weiterwerfen
}

    Du kannst eine eigene Exception dann weiterwerfen, welche zum Beispiel __LINE__ und __FUNCTION__ speichert. Du kannst alles mögliche in die Exception packen und irgendwo speichern.
    Bei einem Absturz wird ja glaub ich auch ein Minidump erzeugt. Den kann man dann analysieren.

    Edit: Ich meinte natürlich __FILE__ ... __FUNCTION__ ist nicht im Standard, wird zum Teil zwar auch unterstützt 😉

    Grüssli

    0
  • V

    hartmut1164 schrieb:

    Ich weiss aber nicht wo der Absturz war. Bei abort () habe ich wenigstens einen core-File und kann nachsehen wo es passiert ist. Gerade dieses "Aufraeumen" vernichtet ja diese wichtige Information.

    da mach ich dann

    __asm int 3;

    oder sowas spaßiges. 🕶

    0
  • H

    volkard schrieb:

    hartmut1164 schrieb:

    Ich weiss aber nicht wo der Absturz war. Bei abort () habe ich wenigstens einen core-File und kann nachsehen wo es passiert ist. Gerade dieses "Aufraeumen" vernichtet ja diese wichtige Information.

    da mach ich dann

    __asm int 3;

    oder sowas spaßiges. 🕶

    Da kann man viel machen ...

    int ErrorHandler::BrutalAbort_Count_Zero (int   iIn)
{
        if (iIn == 0)
                return iIn;
        else
                return (BrutalAbort_Count_Zero (iIn - 1));
}

int ErrorHandler::BrutalAbort (void)
{
        return ((1 + BrutalAbort_Count_Zero (3)) / (BrutalAbort_Count_Zero (BrutalAbort_Count_Zero (2))));
}

    🤡

    Bisher hat noch kein Compiler gemerkt, dass ich hier eine Division durch 0 veranstalte.

    0
Anmelden zum Antworten