Se abbiamo una classe principale e il costruttore dei costrutti principali la nostra classe di setup e inseriamo questa classe in una stringa try in main.
Teoraticamente tutti gli errori andranno a caccia? Se lo faranno, come influenzerà la performance e la manutenibilità? L'applicazione si bloccherà?
Il tuo programma può ancora bloccarsi o comunque non riuscire a eseguire le sue attività:
Il codice di gestione delle eccezioni potrebbe contenere un bug; per definizione il tuo gestore è al di fuori del codice 'protetto' dal tuo try / catch , quindi un errore causerà comunque un arresto anomalo del programma.
Solo perché hai gestito l'eccezione, non significa che il tuo stato del programma sia ancora sano. Il tuo programma potrebbe facilmente finire in uno stato che è effettivamente inutile, perché lo stato interno è lasciato in uno stato incoerente. Il programma quindi genererà continuamente eccezioni e all'utente finale non rimarrà altra scelta che terminare forzatamente il programma.
Inoltre, poiché si rilevano tutte le eccezioni, sarà molto più difficile eseguire il debug di tutto ciò che effettivamente va storto nel programma, e non si può mai essere sicuri che le eccezioni che si vedono siano il risultato di uno stato interno non funzionante dopo un'eccezione precedente è stato gestito o un bug reale.
Meglio lasciare il tuo programma in crash. Almeno allora l'utente finale capisce che il programma si è rotto, e tu come sviluppatore avresti un'idea molto migliore di cosa ha rotto il programma.
Sì e no. Lavoro su sistemi embedded. Quando si verifica un'eccezione non gestita, la registriamo e riavvia il sistema, molto simile a quello che stai suggerendo. Forse 9 volte su 10 il riavvio risolve il problema, almeno abbastanza buono mentre il rapporto delle eccezioni viene analizzato per una correzione. L'altra volta su 10 otteniamo un ciclo di riavvio continuo, che è abbastanza di un problema a parte che teniamo traccia di quanti riavvii sono accaduti e passiamo in modalità "recupero" dopo alcuni tentativi.
In ogni caso, non è una panacea. Si tratta di una piccola bacchetta che applichi per darti il tempo di correggerla per davvero, ed è utile solo se ottieni quei rapporti di eccezione e hai un codice di inizializzazione solido che ripristina veramente lo stato del tuo sistema.
Dipende da languaga ma probabilmente no.
In c #, altri thread che generano eccezioni uccideranno il processo principale in cima alla mia testa.
È irrilevante, tranne che per programmi molto semplici, è probabile che tu finisca in uno stato irrecuperabile con conseguente perdita o perdita di dati, che per la maggior parte degli utenti è molto peggio rispetto all'arresto anomalo dell'applicazione.
L'obiettivo appropriato non è quello di rendere l'applicazione "senza incidenti" ma di rendere l'applicazione affidabile e stabile.
Potrebbe essere possibile ridurre o addirittura eliminare virtualmente gli arresti anomali con la gestione delle eccezioni. Tuttavia, a parità di altre condizioni, questo sostituirà semplicemente i crash con i casi in cui il programma entra in uno stato inutilizzabile.
Questo non ha un aspetto migliore per i tuoi utenti. In effetti, molto probabilmente sarà peggio. Almeno un incidente è un fallimento chiaro e pulito. Un programma in uno stato non funzionante è al massimo ambiguo. L'utente può perdere molto tempo per vedere se l'applicazione è bloccata o semplicemente "pensando". Nel peggiore dei casi può effettivamente causare danni, continuando a compiere azioni, ma in modo corrotto.
Non esiste una scorciatoia per scrivere un codice buono e affidabile.
Leggi altre domande sui tag design architecture