Abbiamo bisogno di una strategia personalizzata per la raccolta delle eccezioni delle applicazioni non gestite. Quali sono le nostre opzioni?

Question

Abbiamo bisogno di una strategia personalizzata per la raccolta delle eccezioni delle applicazioni non gestite. Quali sono le nostre opzioni?

#1 da (2 voti)
#2 da (0 voti)

2

"Eccezione non gestita"

In .NET Framework, le eccezioni non gestite sono le eccezioni che non sono state gestite dall'applicazione stessa e provocano un arresto anomalo. Nel caso di un'applicazione desktop, significa che viene visualizzata una finestra simile a questa:

Perun'applicazioneweb,significaprincipalmenteunHTTP500.

Nelleeccezioninongestite,includoanchequellechesono"gestite globalmente", vale a dire, in un caso di applicazioni desktop, la gestione globale che consiste nel mostrare una finestra personalizzata al posto di quella predefinita di Windows.

Contesto

Quando lavoro come libero professionista, utilizzo la mia soluzione interna per raccogliere eccezioni non gestite da fonti diverse (app Web e app desktop). I risultati raccolti vengono quindi visualizzati su un pannello di monitoraggio in tempo reale e raccolti per analisi future (da collegare a un software di tracciamento dei bug, ecc.)

Attualmente, lavoro in un'azienda in cui non sarei in grado di utilizzare la mia soluzione interna per raccogliere le eccezioni (uno dei motivi è che non accetteranno di inviare tutti i messaggi di eccezione ai miei server) .

Questa azienda non ha una strategia precisa per la raccolta di eccezioni non gestite. L'unica soluzione che è stata utilizzata prima è al tempo stesso rudimentale e fuori questione: consiste nell'invio di ogni eccezione via e-mail.

Ciò significa che per il nuovo prodotto su cui sto lavorando, dovremmo sviluppare una strategia personalizzata per la raccolta di eccezioni non gestite.

Domanda

Posso sempre eseguire manualmente la parte che salverà le eccezioni nel database o nel registro e la parte che le caricherà dal database, da un registro o da Eventi di Windows.

Vorrei evitare di reinventare la ruota e usare qualcosa che è già comunemente usato.

Quali sono le mie scelte? In che modo le eccezioni non gestite vengono solitamente raccolte ed elaborate successivamente?

A proposito:

Esistono librerie che aiutano a raccogliere tali eccezioni?
Esistono prodotti software che consentono di analizzare tali eccezioni?

c# .net exception-handling

posta Arseni Mourzenko 22.08.2013 - 16:31

fonte

2 risposte

0

Nel precedente negozio di sviluppo abbiamo utilizzato Microsoft's Exception Application Block - un'estensione .NET - per catturare le eccezioni in un database e avvisare lo sviluppatore. Avevamo un front end web fatto in casa per accedere ai dati (nessun gioco di parole).

Il blocco applicazioni è progettato per essere altamente configurabile.

Un blended datato di 4GuysFromRolla.com

risposta data 22.08.2013 - 17:26

fonte

Leggi altre domande sui tag c# .net exception-handling

Grafico per mostrare una diminuzione della desiderabilità quando si prendono scorciatoie MPL 2.0. collegamento dinamico a GPL

score 2 · Accepted Answer

In breve: Dipenderà dalla versione di .NET Framework, poiché potrebbe essere gestita in modo diverso in .NET 4.0 che in 2.0.

Una regola generale è che, quando si verifica un errore di runtime (Errore di runtime Giallo Screen of Death - YSOD ) su un'applicazione Web in produzione, è importante notificare uno sviluppatore e registrare l'errore in modo che possa essere diagnosticato in un secondo momento.

Ci sono diverse risorse su questo argomento. Per le applicazioni .NET 2.0 è possibile consultare la panoramica di un post come ASP.NET elabora gli errori di runtime e cerca un modo per far eseguire il codice personalizzato ogni volta che un'eccezione non gestita raggiunge il runtime di ASP.NET.

A partire da .NET 4.0 gli sviluppatori ottengono maggiore flessibilità da Asynchronous Programming Model (modello APM). Maggiori dettagli sono pubblicati qui .

Prior to the .NET Framework 2.0, unhandled exceptions were largely ignored by the runtime. For example, if a work item queued to the ThreadPool threw an exception that went unhandled by that work item, the ThreadPool would eat that exception and continue on its merry way. Similarly, if a finalizer running on the finalizer thread threw an exception, the system would eat the exception and continue on executing other finalizers.

Esistono diversi tipi di strategie di dialogo User Exception Handling che potresti guardare per le applicazioni Windows Form.

In conclusione, ci sono alcune opzioni che dipendono dalla versione di Framework su cui è attualmente eseguita l'applicazione .NET.