Che cosa fare quando si consente all'applicazione di essere eseguita in uno stato non valido?

Questo suona familiare.

Una volta ero il manager di un gruppo con una grande applicazione che aveva alcune eccezioni non gestite che alla fine erano state prese come un gestore globale di catch-all-and-display-the-world-has-ended. Di default questo permetteva di continuare a girare l'applicazione.

Il tuo punto sullo stato dell'applicazione in questo caso è lo stesso che ho fatto: l'applicazione non dovrebbe continuare a funzionare perché il suo stato interno è sconosciuto e molto probabilmente sospetto (dopotutto è così che è stata sollevata un'eccezione in primo luogo ).

Volevo che l'applicazione fosse modificata in modo che l'utente potesse salvare i dati e quindi l'applicazione sarebbe uscita, senza possibilità di continuare. Ciò è stato accolto da una feroce resistenza, principalmente da parte di sviluppatori che hanno sostenuto di aver continuato per un lungo periodo e che ci sono stati danni minimi - solo un sacco di lamentele. Alla fine ho dovuto retrocedere - l'utente poteva continuare, ma le finestre di dialogo sono state modificate per suggerire agli utenti che dovrebbero uscire e riavviarsi. Continuo a pensare che fosse sbagliato.

Alla fine, ogni eccezione che viene vista deve essere analizzata per trovare la causa sottostante e correzioni appropriate, modifiche al codice o qualsiasi altra cosa da applicare in modo che le eccezioni non avvengano - o se lo fanno vengono catturate come parte del normale flusso del programma e gestito localmente.

(A volte, purtroppo, le eccezioni vengono propagate da cose come le librerie.Una delle regole che mi è stata insegnata molto tempo fa era: "non fare mai affidamento sulle eccezioni per il normale flusso di programma". Sembra che questo non sia sempre più regolarmente praticato.)

Sento il tuo dolore - ma alla fine, il principio è semplice e dovresti rimanere fedele ad esso: quando viene sparato l'ultimo gestore di eccezioni, le cose sono davvero malate. Il programma dovrebbe uscire. Fare altrimenti dà agli utenti l'impressione fuorviante di poter continuare a lavorare, ma internamente il programma ha uno stato sconosciuto o rotto. Continuare a lavorare porta solo a peggiorare progressivamente le cose. Alla fine ciò si traduce in perdita di soddisfazione del cliente. I clienti sono anche incazzati da un programma che solleva un'eccezione ed esce - se c'è stato del programma non salvato dovresti provare a salvarlo, forse in un modo che chiarisca che ciò che viene salvato potrebbe non essere affidabile. Almeno riduci la possibilità di perdita di dati. Ma continuando a operare ... brutta mossa sbagliata. Devi scegliere il minore di 2 mali.

Riesco a comprendere il punto che i vostri application manager stanno cercando di fare, che semplicemente spegnendo o riavviando immediatamente dopo aver incontrato un errore imprevisto può confondere un utente. Vuoi sempre dare all'utente le informazioni su ciò che è successo e, se possibile, dare loro una scelta su come vorrebbero gestirlo.

Potresti anche provare a localizzare il problema su un particolare componente che potrebbe forse essere ricaricato o risincronizzato in modo da evitare che altre aree di lavoro dell'applicazione debbano essere rimosse?

D'altro canto, se continuando a lavorare e possibilmente corrompendo dati persistenti che potrebbero causare problemi futuri a se stessi o ad altri, OPPURE se questi dati danneggiati o corrotti necessitano dell'intervento manuale per ripulire in qualche modo, si ha un caso per chiudere l'applicazione il prima possibile. Assicurati solo che sia informativo e aggraziato (... grazioso come un crash dell'applicazione potrebbe essere:)

Forse i tuoi sforzi sono meglio concentrati sulla stabilizzazione dell'applicazione dove le eccezioni impreviste si verificano molto meno e le eccezioni attese si verificano molto meglio.

È assolutamente consigliabile chiudere l'applicazione che ha generato un'eccezione non gestita. Sotto Winforms in .NET, c'era una finestra di dialogo che si apriva e ti dava un grosso avvertimento con l'opzione di continuare a correre. Ma dal momento che penso che .NET 3.5 che continua l'opzione non sia più lì e sei costretto a chiudere l'app.

Se riavviare l'applicazione automaticamente dipende da te - ho visto questo fatto da altri software importanti come i browser.

La finestra di dialogo per il nostro gestore globale di tutte le eccezioni visualizza la traccia dello stack più altre informazioni (nome della macchina, ora, messaggio di errore, nome utente corrente, ecc.) in una casella di testo che può essere copiata negli appunti. Un pulsante è disponibile per il supporto via e-mail con le informazioni (il pulsante è denominato 'Invia rapporto errori'). Nella mia esperienza, l'utente probabilmente non si preoccuperà di informarti che ciò accada, a meno che non venga loro fornito un modo semplice per inviarti un'email. E scrivere i dettagli delle eccezioni in un file di log, mentre è ancora necessario, non sarà di grande utilità per lo sviluppatore finché non avrai accesso al file o alla macchina.

A seconda della situazione c'è una risposta che ho usato una volta: se qualcosa va in tilt ma non è certo una fatalità resetto il nome del documento - se il lavoro viene corrotto non sovrascrive l'originale. Era inteso solo per consentire loro il tempo per un'uscita aggraziata.