Break in Class Module vs. Break su Errori non gestiti (VB6 Error Trapping, Options Setting in IDE)

Fondamentalmente, sto cercando di capire la differenza tra “Break in Class Module” e “Break on Unhandled Errors” che appaiono nell’IDE di Visual Basic 6.0 nel seguente percorso:

Tools --> Options --> General --> Error Trapping 

Le tre opzioni sembrano essere:

  • Break on All Errors
  • Break in Class Module
  • Interruzione degli errori non gestiti

Ora, apparentemente, secondo MSDN, la seconda opzione (Break in Class Module) significa davvero “Interruzione degli errori non gestiti nei moduli di class”. Inoltre, questa opzione sembra essere impostata di default (ad esempio: penso che sia impostato su questo fuori dalla scatola).

Quello che sto cercando di capire è, se ho la seconda opzione selezionata, ottengo la terza opzione (Break on Unhandled Errors) gratuitamente? In questo, viene incluso di default per tutti gli scenari al di fuori dello spettro del modulo di class? Per consigliare, non ho alcun modulo di class nel mio progetto attualmente attivo. Ho i moduli .bas però. Inoltre, è ansible che con Class Mdules si possa fare riferimento anche ai normali moduli .bas? (questa è la mia seconda sotto-domanda).

Fondamentalmente, voglio solo che l’impostazione assicuri che non ci saranno sorprese una volta che l’exe verrà rilasciato. Desidero visualizzare quanti più errori ansible mentre sono in fase di sviluppo e non visualizzarli quando si è in modalità di rilascio. Normalmente, ho due tipi di On Error Resume Next sui miei moduli in cui non esiste una gestione esplicita degli errori, sono i seguenti:

In caso di errore, riprendi ‘REQUIRED ON Error Resume Next’ NON RICHIESTO

Quelli richiesti sono cose come, controllando se un array ha una lunghezza qualsiasi, se una chiamata al suo UBound commette errori, significa che non ha lunghezza, se restituisce un valore 0 o più, quindi ha lunghezza (e quindi , esiste). Questi tipi di dichiarazioni di errore devono rimanere attive anche mentre sto sviluppando. Tuttavia, quelli NON NECESSARI non dovrebbero rimanere attivi mentre sto sviluppando, quindi li ho tutti commentati per assicurarmi di cogliere tutti gli errori esistenti.

Una volta che sono pronto per rilasciare l’exe, faccio un CTRL + H per trovare tutte le occorrenze di:

‘On Error Resume Next’ NON RICHIESTO

(Potresti aver notato che sono stati commentati) … E sostituirli con:

In caso di errore, riprendi ‘NON RICHIESTO

… La versione non commentata, in modo che in modalità di rilascio, se ci sono errori rimanenti, non mostrano agli utenti.

Per ulteriori informazioni sulla descrizione di MSDN sulle tre opzioni (che ho letto due volte e che ancora non trovi adeguate) puoi visitare il seguente link:

http://webcache.googleusercontent.com/search?q=cache:yUQZZK2n2IYJ:support.microsoft.com/kb/129876&hl=en&lr=lang_en%7Clang_tr&gl=au&tbs=lr:lang_1en%7Clang_1tr&prmd=imvns&strip=1

Sono anche interessato a sentire i tuoi pensieri se hai voglia di offrirli volontariamente (e questa sarebbe la mia terza domanda parziale / totalmente facoltativa, cioè, i tuoi pensieri sulle tecniche di gestione degli errori di fallback).

Per riassumere, le prime due domande erano: otteniamo l’opzione 3 inclusa in tutti gli scenari non di class se scegliamo l’opzione 2? E, è ansible che quando usano il termine “Modulo di Classe” possano riferirsi anche ai moduli .bas? (Poiché un modulo .bad è in realtà solo un modulo di class che viene pre-istanziato in background durante l’avvio).

Grazie.

Inizierò con la prima opzione. Interruzione di tutti gli errori disabilita semplicemente i gestori degli errori. Ciò è utile quando si tenta di eseguire il debug dopo aver inserito i gestori degli errori, perché si possono avere errori negli handler stessi, oppure si può perdere traccia di dove si è verificato l’errore quando l’errore genera una gerarchia di contenimento (errori che non sono viene gestito in una procedura che tenta di trovare un gestore in una procedura di chiamata, il che può creare confusione se si sta tentando di trovare la riga di codice incriminata).

Successivamente, l’interruzione degli errori non gestiti non si interrompe in un modulo di class se c’è una riga di codice che causa un errore. Se hai questa opzione impostata e chiami un metodo in una class e c’è un errore nella riga di codice nel metodo, interromperai la linea nel tuo client che ha la chiamata al metodo.

L’interruzione del modulo di class passa alla riga di codice della class che presenta l’errore. Un avvertimento a questo è che se si sta lavorando con un EXE ActiveX, l’impostazione di controllo è nel suo progetto piuttosto che nel progetto client. Cioè, puoi avere un’interruzione di tutti gli errori impostati nel tuo progetto client e interrompere gli errori non gestiti impostati nel tuo progetto EXE ActiveX, e non interromperesti il ​​modulo di class perché stai lavorando con due processi separati.

Preferisco personalmente lasciarlo impostato su break in module module, perché mi consente di eseguire il drill-down del sito dell’errore con la massima precisione. Questo è prima che comincio a fare gestori di errori, però; a quel punto generalmente rimbalzo intorno a tutti e tre, a seconda di cosa sto cercando di stabilizzare.

Infine, NON raccomando MAI di utilizzare Errore in Ripresa Avanti, tranne nel contesto della gestione degli errori in linea.

Sì, quando si seleziona “Break in module module”, esso si interrompe ancora in errori non gestiti, ma si interromperà anche su QUALSIASI errore nei moduli di class (non semplici moduli) che non sono gestiti nel modulo stesso.

Confrontalo con “interruzione degli errori non gestiti” che causerà l’uscita dal codice di controllo class / utente quando si verifica un errore all’interno di esso, rendendo difficile rintracciare la posizione esatta.

Probabilmente è meglio lasciarlo impostato sulla “interruzione degli errori non gestiti” per lo sviluppo generale in quanto gli altri diventeranno fastidiosi quando si gestiscono errori che sono benigni. Si noti che è meglio provare a rilevarli prima che attivino un errore.