Modello ad oggetti di ASP.NET

[majorTom]

Ciao a tutti...

Ho creato una libreria di classi che utilizzo in alcuni miei progetti, sia web che windows.

con il web ho il grosso problema di non riuscire a gestire gli errori.
mi spiego meglio.

dalle mie classi, importate nel progetto principale come reference,
vorrei poter accedere agli oggetti della pagina web per dare un feedback di un eventuale errore.
in caso non fosse possibile mi basterebbe perlomeno riuscire a stampare un classico
response.write con l'eventuale messaggio di errore.

Così facendo sono costretto a delegare la gestione dell'errore alla form che usa le librerie, e non mi piace come cosa...

C'è qualche soluzione???

[djciko]

non sono sicuro di aver ben capito la problematica...

ma tanto per parlare, le eccezioni non gestite nel framework si possono, appunto, gestire in vari modi :

- blocchi try...catch....finally
- routine centralizzate a livello pagina (Page ErrorPage="paginaErroreDefault.aspx")
- routine centralizzate a livello applicazione (Nel global.asax, le sub Global_Error ed Application_Error)
- pagine di errore per le eccezioni ESTERNE all'applicazione (i classici "rimpiazzi" delle varie 404 etc, da settare nell'application server, IIS)
- registro di raccolta delle eccezioni dell'applicazione (nel web.config, <trace=true>)

puoi poi estendere la classe -ApplicationException- per creare nuove eccezioni e lanciarle con la parola chiave -throw- ...

[pietro09]

sottolineo la risposta di djciko.

Comunque, se ho una routine generale, risolvo l'eccezione in locale, solo se posso.
Ad esempio, se cerco di leggere un file da un cd non pronto, è facile dare il messaggio: disco non pronto.
Negli altri casi, rilancio l'eccezione al chiamante, senza vergognarmene. E non riesco proprio a capire la logica di fare altrimenti. Come posso gestire nella procedura A le problematiche di un progetto X o Y? :master:

[djciko]

esatto...in altre parole, la gestione delle eccezioni deve essere "rasoterra"...a meno che la libreria in uso non è progettata apposta, nei suoi metodi, per restituire, che so, -1 dopo aver intercettato una eccezione. in quel caso si puo' gestire l'eccezione anche a livello piu' esterno...

per es, per il login di un utente:

Namespace CustomExceptions
    Public Class UtenteNonTrovatoException
        Inherits ApplicationException
        Sub New(Optional ByVal message As String = "Utente non trovato in archivio", Optional ByVal inner As Exception = Nothing)
            MyBase.New(message, inner)
        End Sub
    End Class
End Namespace

e nel metodo "login" della classe "utente.vb"

        .
        .
        .
        Try
            conn.Open()
            cmdLogin.ExecuteNonQuery()

            If cmdLogin.Parameters("@id").Value <> -1 Then
                valoreritorno = 0
            Else
                Throw New CustomExceptions.UtenteNonTrovatoException
            End If
        Catch ex As CustomExceptions.UtenteNonTrovatoException
            Trace.Warn("WARNING: " & ex.Message)
            valoreritorno = -1
        Finally
            conn.Close()
            cmdLogin.Dispose()
            Return valoreritorno
        End Try

e nella pagina aspx che istanzia la classe utente:

 if utente.login = -1 then response.write("errore nel login")

[majorTom]

Intanto grazie per le risposte...

provo però a spiegarmi un po' meglio...

in realtà il problema è un po' più esteso,
la problematica della gestione degli errori è solo uno dei casi

in pratica, nella mia libreria di classi io vorrei riuscire ad usare le collezioni
e gli oggetti proprie delle pagine web.

per fare 2 esempi:
dalle mie classi non riesco ad utilizzare la direttiva
Server.Mappath (nome server non dichiarato).
Per fare il debug mi piacerebbe (anche se so che non è il metodo giusto) poter fare
un response.write all'interno della libreria, ma anche questo non riesco a farlo...

Boh... sono alle prime prove di asp.net in questo senso, magari è una cavolata...

[djciko]

nella tua classe scrivi

HttpContext.Current.

ed avrai a disposizione gli oggetti che ti servono (server, response etc)

[Kahm]

secondo me basta che nelle funzioni delle dll ti fai ritornare un errore oppure una propertu pubblica in cui controlli se è valorizzata, la quale conterra' l'errore

esempio nella dll:

public function cerca as string
try
command.execute
catch
return ex.exceptiont & " " & ex.descriziption
end try
end function

oppure una property pubblica penso che vada bene e nel web form ogni volta ti vai a vedere se è pieno o meno

[riccardone]

Originariamente inviato da Kahm
secondo me basta che nelle funzioni delle dll ti fai ritornare un errore oppure una propertu pubblica in cui controlli se è valorizzata, la quale conterra' l'errore
esempio nella dll:
...
oppure una property pubblica penso che vada bene e nel web form ogni volta ti vai a vedere se è pieno o meno

Non mi sembra un buon modo di gestire gli errori. Non vedo la ragione per mettere in una dll un blocco try catch che non fa altro che restituire il messaggio e qualche altra informazione (ancora peggio mettere queste informazioni dentro una property!). Tanto meglio che la funzione che incontra una eccezione ritorni a chi la sta usando l'eccezione stessa. Se nella funzione e' necessario gestire le risorse rimaste aperte (vedi connection) basta mettere il tutto in un blocco try finally (senza il catch) e nel finally chiudere le risorse.
La regola da seguire per la gestione degli errori in una situazione clientwebowin -> dll e' che le eccezioni vengano gestite dal client della libreria. Se vi e' la necessita' di gestire una o piu' eccezioni personalizzate si possono creare tutte le eccezioni che servono con poche righe di codice (cosi come consigliato piu' sopra) e nel cliente inserire dei
catch ex as tuacustomexception

Originariamente inviato da djciko
....e nella pagina aspx che istanzia la classe utente....

ma non sarebbe meglio mettere direttamente nella pagina aspx (file .vb o .aspx a seconda se si usa il codebehind o meno) qualcosa di simile a

....
try
utente.login("user", "pass") 
catch exLogin as UtenteNonTrovatoException
response.write("errore nel login")
end try

....

[riccardone]

Originariamente inviato da majorTom
in realtà il problema è un po' più esteso,
....
dalle mie classi non riesco ad utilizzare la direttiva
Server.Mappath (nome server non dichiarato).
Per fare il debug mi piacerebbe (anche se so che non è il metodo giusto) poter fare
un response.write all'interno della libreria, ma anche questo non riesco a farlo...

lasciami dire che poter fare in una libreria un response.write o utilizzare un qualsiasi metodo proprio di una interfaccia utente (web o win) e' una pessima idea (teoricamente possibile se referenzi nella libreria le dll giuste). In pratica il componente sarebbe legato geneticamente all'interfaccia utente (web nel tuo esempio) e non potrebbe essere riutilizzato facilmente per una diversa interfaccia es. win. Tantovarrebbe allora creare le varie classi direttamente nel progetto web e utilizzare tutti i metodi propri di questo ambiente.

[djciko]

Originariamente inviato da riccardone
lasciami dire che poter fare in una libreria un response.write o utilizzare un qualsiasi metodo proprio di una interfaccia utente (web o win) e' una pessima idea (teoricamente possibile se referenzi nella libreria le dll giuste). In pratica il componente sarebbe legato geneticamente all'interfaccia utente (web nel tuo esempio) e non potrebbe essere riutilizzato facilmente per una diversa interfaccia es. win. Tantovarrebbe allora creare le varie classi direttamente nel progetto web e utilizzare tutti i metodi propri di questo ambiente.

è giusto. La progettazione di un componente dovrebbe essere quanto più possibile slegata dal contesto di esigenza immediato. In poche parole, bisognerebbe pensare lontano ed a 360°. Ma spesso per la fretta di far funzionare le cose ce ne dimentichiamo...Pagando poi dopo in riusabilità