Otterenere errore via mail

[duality]

Ciao a tutti,
mi chiedevo se esiste un modo per ottenere via mail la pagina generata dall'applicazione in caso di errore.
In pratica mi servirebbe che ogni volta che la mia applicazione crasha arrivi nella mia mailbox la classica pagina con l'errore in rosso:



Grazie in anticipo.

[Marconline]

Fai una classe che deriva da Page e fai derivare tutte le tue pagine da questa.

Nella classe, quindi, sovrascrivi il metodo OnError:
protected override void OnError(EventArgs e)

Da lì puoi fare quel che vuoi!

Per maggiori info vai qui: http://aspnetresources.com/articles/...rrorPages.aspx

Ciao,
Marco

[riccardone]

Classe che deriva da page?
Asp.net mette a disposizione metodi molto più semplici per gestire eccezioni non gestite.
A livello di pagina esiste l'evento Page_Error.
A livello di applicazione esiste l'evento Application_Error nel global.asax.
In alternativa, puoi impostare nel web.config una o più pagina specializzate per ogni tipo di errore non gestito (e/o per tutti gli errori) in modo da presentare all'utente un messaggio personalizzato con il layout del sito e gestire l'eccezione come meglio si crede.

[Marconline]

Mi insegnerai che di modi per risolvere un problema ce ne sono milioni, ma se leggi esattamente cosa ha chiesto duality il discorso è ben diverso.

La soluzione che ho proposto si basa sul Page Controller Pattern, pattern noto che, appunto, prevede di far derivare tutte le tue pagine da una classe creata da te che a sua volta deriva da Page.

Questa soluzione è da adottare, a mio avviso, per qualunque progetto perchè ti garantisce di poter inserire immediatamente la business logic comune modificando un file solo. Un altro caso in cui può tornare utile sono quando istanzi le classi helper che si interfacciano con il Data Layer.

Chiudo, quindi, dicendo che - a mio personalissimo giudizio - le soluzioni che hai proposto sono sicuramente valide, ma penso poco flessibili.

Ciao,
Marco

[riccardone]

Originariamente inviato da Marconline
La soluzione che ho proposto si basa sul Page Controller Pattern, pattern noto che, appunto, prevede di far derivare tutte le tue pagine da una classe creata da te che a sua volta deriva da Page.

Mi sfugge un po' quale pattern suggerisci. Non mi sembra che quanto da te proposto possa corrispondere ad un qualche pattern, tantomeno al pattern che prevede tra le altre cose un controller che gestisce le richieste es. Model View Controller
http://martinfowler.com/eaaCatalog/pageController.html

quanto da te proposto introdurrebbe seri problemi in qualsiasi progetto si utilizzasse perchè crea una inutile dipendenza tra le classi derivate e la classe base che irrigidisce l'architettura e non il contrario.

Questa soluzione è da adottare, a mio avviso, per qualunque progetto perchè ti garantisce di poter inserire immediatamente la business logic comune modificando un file solo. Un altro caso in cui può tornare utile sono quando istanzi le classi helper che si interfacciano con il Data Layer.

Quindi, fammi capire il tuo pattern. Dici che dovrei fare una classe derivata da page al cui interno metto le funzioni utili e la logica di accesso ai dati?

Chiudo, quindi, dicendo che - a mio personalissimo giudizio - le soluzioni che hai proposto sono sicuramente valide, ma penso poco flessibili.

De gustibus. Qualche anno di esperienza e la documentazione di asp.net dicono il contrario.

[Marconline]

Sull'esperienza non discuto: sicuramente tu hai avuto le tue come io ho avuto e ho tutt'ora le mie. Gli studi che ho fatto e l'esperienza lavorativa che da anni porto avanti mi danno sicurezza su ciò che dico.

Per quanto concerne il pattern, è semplice: nella classe che (in pratica) si frappone tra la classe della tua pagina e la Page (e quindi non crea ulteriori dipendenze, rispetto a quella che già c'è con Page), inserisci la logica comune per tutte le pagine e i riferimenti ad eventuali classi il cui scopo è fare da interfaccia (normalmente chiamate helper) con il database.

In questo modo ogni pagina conosce gli helper disponibili (e se ne aggiungi qualcuno dopo ti è sufficiente modificare la tua classe base e tutte le pagine lo sapranno) e, se la prepari bene, li fa istanziare solo quando sono richiesti per non creare overhead inutili.

Il pattern è noto e riportato in svariate bibliografie. Il link che ho riportato ripete esattamente ciò che dico io:

This works for one page only, you may say. To have every page benefit from this kind of error handing we need to take advantage of the Page Controller pattern. You define a base class and have every page inherit from it.

Ciao,
Marco

[riccardone]

Originariamente inviato da Marconline
Per quanto concerne il pattern, è semplice: nella classe che (in pratica) si frappone tra la classe della tua pagina e la Page (e quindi non crea ulteriori dipendenze, rispetto a quella che già c'è con Page), inserisci la logica comune per tutte le pagine e i riferimenti ad eventuali classi il cui scopo è fare da interfaccia (normalmente chiamate helper) con il database.

La dipendenza viene creata tra le pagine derivate e la nuova classe base. Un conto è stabilire una dipendenza con una classe del framework (page) che verosimilmente non cambierà. Un conto è derivare ogni classe da una classe custom che oggi è fatta in un modo e domani potrebbe cambiare rompendo a destra e a manca il funzionamento di tutte o parte delle pagine derivate. Peggio che andar di notte se inseriamo in una classe che deriva da page che è nel namespace asp.net un riferimento al dal o a funzioni di accesso ai dati. Domani che vuoi riutilizzare la stessa logica per una applicazione stand alone ti tocca riscrivere mezzo programma.

Il pattern è noto e riportato in svariate bibliografie. Il link che ho riportato ripete esattamente ciò che dico io:

Quale pattern? Dimmi il nome. Il link che hai riportato (scritto nel 2004) è scritto bene finche' copia e incolla dalla documentazione ufficiale quello che ho ripetuto anche io e cioè che per gestire gli errori si può sceglere se:
- farlo a livello di pagine con Page_Error
- farlo a livello di applicazione con Apllication_Error o modificando il web.config
- aggiungere gestioni specifiche per specifici errori nel web.config

Lo scrittore dell'articolo che hai riportato ha inserito una frase, forse l'unica farina del suo sacco, e cioè quella che hai riportato tu. Se segui il link su msdn ti troverai a che fare con il pattern MVC che è ben altra cosa e non considera neanche lontanamente una classe che deriva da page e che diventa la classe base di tutte le pagine della applicazione web.

[Marconline]

Sinceramente non capisco dove stia il problema... La classe diventa semplicemente un wrapper di altri oggetti... Come può rompere le altre pagine? Questo succederebbe se e solo se gli oggetti che vengono contenuti non funzionino... Sono gli oggetti che vengono contenuti che fanno accesso ai dati, anzi si interfacciano ad un altro oggetto (almeno per come sviluppiamo noi in azienda) che si occupa di interfacciarsi al database. Quindi la logica è assolutamente slegata dalla base dati.

Per il resto è semplicemente un modo diffuso di programmare e, visto che è da anni che lo uso e non ha mai dato problemi, direi anche efficiente. Il nome del pattern non lo conosco, l'avevo preso da lì pensando che fosse quello. Non per questo non è un pattern (ovvero una soluzione nota ad un problema ricorrente).

Rimane il fatto che farlo a livello di pagina (per ogni singola pagina) usando il Page_Error è certamente una soluzione (non ho mai detto che non lo sia, nè per questa nè per le altre), ma è davvero inefficiente: replicare lo stesso pezzo di codice su n pagine non fa altro che aumentare il carico di manutenzione di un coefficiente n. La mia soluzione, che ti piaccia o no, evita proprio questo problema.

Ciao,
Marco

[riccardone]

Originariamente inviato da Marconline
Come può rompere le altre pagine?

semplicemente cambiando l'implementazione di un metodo che le classi derivate utilizzano.

...replicare lo stesso pezzo di codice su n pagine non fa altro che aumentare il carico di manutenzione di un coefficiente n. La mia soluzione, che ti piaccia o no, evita proprio questo problema.

non c'e' 4 senza 5. Per l'ennesima volta:

[esempio di gestione che non va ripetuta in ogni pagina]
- farlo a livello di applicazione con Apllication_Error o modificando il web.config <<<<
- aggiungere gestioni specifiche per specifici errori nel web.config
[/esempio di gestione che non va ripetuta in ogni pagina]

[Marconline]

Se tu ripeti per 5 io ripeto per 6

non ho mai detto che le tue non siano soluzioni Ho sempre detto che (A MIO PARERE) prima di gestire in ogni pagina il page_error si poteva usare questo trucco.

A dimostrazione del fatto che non sono l'unico "fuori di testa" a cui piace "andare di notte", incollo qualche link che parlano proprio di questo, citandolo addirittura come esempio fondamentale dell'OOP.

In questo articolo scrive Scott Mitchell su 4GuysFromRolla. Ha scritto diversi libri tra cui 5 dedicati ad asp.net.

In quest'altro invece scrive Robert Boedigheimer, speaker di diverse Conference Microsoft.

In quest'ultimo scrive Brad McCabe, dipendente Infragistic (azienda nota per custom controls) e considerato "Evangelista di ASP.net"

Ce ne sono tanti altri, basta cercare su Google Custom Base Class o similari.

Marco