Come gestire le eccezioni nelle DLL?

1

Recentemente ho iniziato a lavorare su un progetto esistente scritto in C ++ Builder. L'applicazione consiste in un MainModule che carica LOT di moduli (DLL). Il MainModule stesso è una DLL (c'è un piccolo caricatore (.exe) che avvia il MainModule).

Il MainModule non dovrebbe bloccarsi se compare un problema in uno dei moduli caricati (DLL). Quindi, è IMPERATIVO che le eccezioni non lascino il / i modulo / i. Pertanto, in ogni DLL esiste una prova / cattura globale che intercetta tutte le eccezioni all'interno.

Per rendere il codice più compatto, vengono utilizzate eccezioni OVUNQUE (gestione delle eccezioni strutturate) per
   * controllo del flusso
   * segnalazione di cose
   * registrazione degli errori (quando accade qualcosa di sbagliato, il gestore delle eccezioni invierà un messaggio alla console).

Il debug viene eseguito in base ai messaggi mostrati nella console e anche le linee printf sono inserite nel codice per vedere se il programma raggiunge o meno un determinato punto di una funzione.

Mi chiedo, come posso eseguire il debug di queste DLL?
Il problema è che quando una violazione di accesso si verifica in uno di questi plugin / DLL, il try / catch globale cattura l'eccezione. Non arriverà mai all'applicazione / debugger principale.

Nota: il codice è revisionato. Pertanto, è anche IMPERATIVO fare meno modifiche possibili al codice esistente!

    
posta Rigel 05.07.2018 - 14:30
fonte

2 risposte

2

Vedo due approcci al tuo problema:

  • Configura il debugger da interrompere quando viene lanciata un'eccezione e non solo su eccezioni non gestite. Questo è l'approccio che scelgo di solito, ma funziona solo se le eccezioni vengono utilizzate solo per eventi eccezionali e non sempre. Quindi non sembra adattarsi molto bene alla tua applicazione.

    Alcuni debugger consentono di configurare queste impostazioni in base al tipo di eccezione. Pertanto, puoi utilizzare questo approccio per le eccezioni che non dovrebbero mai accadere (ad esempio violazioni di accesso) mentre ricorrere al secondo approccio per le eccezioni che si verificano frequentemente nel tuo codice base.

  • Potresti inserire un break-point nel gestore di eccezioni globale nella dll.

    Qualcosa sulla falsariga di: if( IsDebuggerPresent() ) __debugbreak() ;

    Purtroppo parte dello stack sarà già srotolata da quel punto, rimuovendo molte informazioni utili per il debug.

Anche se è improbabile che tu possa fare qualcosa al riguardo, una violazione di accesso è generalmente considerata un'eccezione irrecuperabile (perché potrebbe derivare da / in un danneggiamento della memoria) e dovresti usare un processo separato che viene terminato per contenere il fallout invece di lasciando che un processo continui in cui si è verificato tale errore.

    
risposta data 06.07.2018 - 10:23
fonte
3

'deglutire' in generale un'eccezione strutturata è molto pericoloso. Lo fai solo con le eccezioni che ti sei innescato intenzionalmente? I. E. Se ingerisci un segfault, questo potrebbe in modo subdolo corrompere il tuo processo e rendere il problema quasi impossibile eseguire il debug quando DAVVERO rovina in un secondo momento.

Suggerirei di isolare i tuoi sottomoduli in processi separati, se possibile

    
risposta data 06.07.2018 - 08:56
fonte

Leggi altre domande sui tag