Conosco le differenze tra i due. Una cosa degna di nota è che abort() invia il segnale SIGABRT, quindi potrebbe essere rilevante quando il software si basa su di essi. Ma per una tipica applicazione exit() sembra essere la versione più sicura di abort() ...? Ci sono altri dubbi sull'uso di abort() invece di exit()?Quando si preferisce abort() su exit()?
L'utilizzo di abort eseguirà il dump di core, se l'utente dispone di core dump abilitati. Quindi, come regola generale, utilizzerei lo abort se sei così insicuro su ciò che è andato storto che l'unico modo per ottenere informazioni utili è analizzare un core dump.
Se è possibile impostare in modo sicuro exit da un punto qualsiasi e non è necessario il core dump, l'uscita è un approccio più gradevole.
A volte il programma si interrompe a tal punto che il suo stato diventa incoerente e quindi exit() non funzionerà perché causerebbe la distruzione di oggetti globali e quest'ultimo non funzionerebbe correttamente quando lo stato è incoerente. In tali situazioni è preferibile il abort().
Suppongo che sia ad esempio quando l'I/O diventa non operativo a causa dell'errore dell'HDD? Si cattura questo come un'eccezione ma non è possibile distruggere gli oggetti file perché i loro distruttori devono eseguire la chiusura del file. Grazie per l'idea. – doc
@doc: Sì, ma è un esempio piuttosto estremo. Un esempio più C++: stai già gestendo un errore e si verifica un altro errore (non correlato al processo di gestione degli errori) e il codice di gestione viene reinserito. Non è molto bello - gli errori si verificano più velocemente che puoi gestirli. Quindi mantieni una bandiera "Sto già gestendo questo tipo di errore". Una volta che il codice è rientrato, getti la spugna - chiama 'abort()' per terminare immediatamente il programma. – sharptooth
Ecco perché non si "getta" dai distruttori. Se il distruttore viene chiamato durante lo srotolamento dello stack causato da un'eccezione, viene chiamato 'abort()'. –
Utilizzare abort() se il programma si trova in uno stato potenzialmente danneggiato e lo si considera troppo pericoloso per cercare di fare qualcosa di più. exit() causerà la chiamata di qualsiasi funzione atexit e di distruttori C++ di oggetti statici. Questo di solito è ciò che si desidera per un'uscita pulita, ma potrebbe essere catastrofico se, ad esempio, sovrascrivono un file con dati corrotti.
+1: ma hai anche altri modi per farlo. per non chiamare la funzione registrata come atexit potresti anche _exit() invece di exit(), o anche inviare un SIGKILL a te stesso per l'uscita immediata. – kriss
@Kriss: 'abort()' è il modo standard per farlo e facile. Perché dovresti scegliere un metodo non standard? – MSalters
@kriss: '_exit()' non è standard C o C++, e abortire alzando un segnale diverso da 'SIGABRT' sembra una cosa un po 'strana da fare. –
L'interruzione viene preimpostata quando l'applicazione non è in grado di gestire l'eccezione e non è in grado di comprendere lo scenario da eseguire. L'applicazione media di Exit() deve terminare correttamente tutte le attività. se si verifica un'eccezione e l'applicazione è in grado di gestire lo stesso, si verifica una chiamata a Exit().
anche questo è un buon punto +1 – doc
Vorrei riformularlo così: ti aspetti che i tuoi utenti possano analizzare i core dump? Altrimenti, non abortire. (Tenendo presente che sebbene lo sviluppatore possa desiderare un core dump, i vostri utenti potrebbero non farlo. Quindi forse abortire dovrebbe essere usato solo in una versione "debug" del vostro eseguibile.) –
@Ken Simon: Se gli utenti non vogliono core discariche, possono disattivarle (ulimit -c 0). Penso che Ubuntu lo faccia per impostazione predefinita. – camh