4. Code will keine Exception fangen

Code will keine Exception fangen

  • S

    Ich hab eine Zeile, die so aussieht:

    try
	{
db.dbUniqueId[1] = database.dbUniqueId[1];

}catch (...)
	{
		throw std::exception(headerMemoryError.c_str());
	}

    in bestimmten Fällen kann das nicht klappen, weil die Zuweisung nur aus "" besteht, das ist auch ok so, denn es ist in einem try catch block.
    Im Debug liefert mir der Fehler eine "Debug Assertion Failed!"- Meldung. Die kommt von der Stringzuweisung.

    In der Debug-config habe ich bereits versucht das _DEBUG Macro in NDEBUG zu ändern, kein Erfolg, gleiches Problem.

    Dann bin ich zur Release-config gewechselt, aber ansatt in den Catch block zu springen, bekomme ich an der Stelle folgendes:

    Microsoft Visual Studio C Runtime Library has detected a fatal error in parent.exe.

    Press Break to debug the program or Continue to terminate the program.

    Weder mit break noch continue komme ich in den catch block. Woran liegt das?

    Er springt immer in "dbghook.c" an die folgende Stelle:

    _declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
    /* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
    (_Reserved);
    _debugger_hook_dummy = 0;
}

    Der obere code inklusive catch wird als DLL exportiert und von parent.exe aufgerufen.
    Oder ist der code, den ich genutzt habe, nicht in der lage eine exception zu werfen?
    database.dbUniqueId[1]; ist std::string, die assertion wird jedoch von xstring von VC gerufen

    0
  • A

    Seikilos schrieb:

    Dann bin ich zur Release-config gewechselt, aber ansatt in den Catch block zu springen, bekomme ich an der Stelle folgendes:

    Microsoft Visual Studio C Runtime Library has detected a fatal error in parent.exe.

    Das deutet auf einen Fehler hin, für die keine Exceptions berücksichtigt werden. Ich weiß gar nicht ob die MFC das C++ Exceptionhandling verwendet.

    Des weiteren:

    Seikilos schrieb:

    Der obere code inklusive catch wird als DLL exportiert und von parent.exe aufgerufen.

    Man sollte niemals Exceptions über DLL-Grenzen werfen (oder sicherstellen das es mit dem verwendeten Compiler wirklich funktioniert, das wäre dann aber Compilerabhängig).

    cu André

    0
  • Mod

    ASSERTs kann man nicht mit try catch abfangen. ASSERTs sind meistens darauf zurückzuführenm, dass Du eine Funktion/Klasse mit unerlaubten Parametern oder nicht in der korrekten Weise verwendest.

    Dann schau doch einfach mal hin woher der ASSERT kommt. Dein Callstack müsste doch Auskunft darüber geben.

    0
  • S

    Kommt aus der xstring

    #if _HAS_ITERATOR_DEBUGGING
		// skip debug checks if the container is initizialed with _IGNORE_MYITERLIST
		if (this->_Myfirstiter != _IGNORE_MYITERLIST)
			{
			if (_Mysize < _Off)
				{
				_DEBUG_ERROR("string subscript out of range");
				_SCL_SECURE_OUT_OF_RANGE;
				}
			}
 #else

    Mir ist ja klar, dass asserts nichit gefangen werden, daher hab ich auch testweise auf Release kompiliert, da müsste doch jede Assertion aus sein. Im Release wird dann halt keine assertion bemerkt sondern erst der eingetliche Fehler. Aber heißt das, dass dieser nicht in der Lage ist, ne exception zu triggern?

    0
  • Mod

    Ich verstehe Deine Frage nicht!
    1. In der Release Version gibt es keine Test, die Deinen Iterator prüfen.
    2. In der Release Version passiert also nichts, oder es gibt einen ZUgriff auf ungültigen Speicher (Crash). Dies kann man aber nicht mit catch(...) abfangen! Das ist eine SEH Exception!

    Also Debugge. Kümmere Dich um Deinen ASSERT, löse den Fehler den Du in den Code gebaut hast und gut ists...
    Fehler und Crashes mit try/ctach oder gar SEH Exceptions zu behandeln ist der größe Humbug, den ein Programmierer treiben kann.

    0
Anmelden zum Antworten