returnera värde till en label

Det borde väl gå att bara göra en publik variabel i default.aspx, så här nånting:

public string ErrMsg {
  set {
    MinLabel.Text = value;
  }
}

Och blir det fel så sätter du ErrMsg helt enkelt.

Fredde Mannen skrev:

Kan jag på något sätt skicka det direkt till en label (ex. labeln ErrMsg) som finns om den sidan som jag använder mig av DbFunctions på, alltså i Default.aspx?

Usch... Det gör ont i själen när du skriver något sådant...

Varför i hela världen skall ditt DataAccessLager (DAL) ha beroende till till presentations lager. Det är en riktigt dålig ide.

Ditt DAL skall inte ha en susning om vem som har anropat det, det skall kunna vara en ASP.NET sida, en WinForms, en WinService. Och hur skall du presenterar felmeddelandet i en WinService eller en WebService som inte har något grafisktgränssnitt.

Nej. Ditt DAL skall (om det inträffar ett fel) kasta vidare den exception som inträffade, eller ännu bättre en egen exception som du skapat själv. Och så skall den applikation/lager som anropat DAL:et fånga denna exception och sedan bestämma vad som skall göras med den, är det en websida? Ja då öppnar vi vår speciella felsida, är det en winform? Ja då slänger vi upp en popup, är det en webservice? Ja då loggar vi felet till en databas och skickar iväg ett mail till sysadmin om felet... eller vad vi nu kan hitta på.

Generellt kan man säga så här. Alla din applikationer bygger på lager. UI->Business->DAL-DataStorage. Och man har bara beroende neråt i lagerna. Så UI känner till allt om Business, men Business vet inget om UI (den vet inte om det är en winform eller webform, och den bry sig inte heller) däremot så vet den allt om DAL (som UI inte vet något om, den känner bara till business) DAL:et vet inget om business inte heller om UI. Men däremot allt om din data som finns lagrad i din datastorage.

Så man har bara beroende på ETT håll... Aldrig Två!!! (det finns undantag, men det tar vi inte upp här, och det är väldigt väldigt sällan)...

- M

Gladh skrev:

Fredde Mannen skrev:

Kan jag på något sätt skicka det direkt till en label (ex. labeln ErrMsg) som finns om den sidan som jag använder mig av DbFunctions på, alltså i Default.aspx?

Usch... Det gör ont i själen när du skriver något sådant...

Varför i hela världen skall ditt DataAccessLager (DAL) ha beroende till till presentations lager. Det är en riktigt dålig ide.

Ditt DAL skall inte ha en susning om vem som har anropat det, det skall kunna vara en ASP.NET sida, en WinForms, en WinService. Och hur skall du presenterar felmeddelandet i en WinService eller en WebService som inte har något grafisktgränssnitt.

Nej. Ditt DAL skall (om det inträffar ett fel) kasta vidare den exception som inträffade, eller ännu bättre en egen exception som du skapat själv. Och så skall den applikation/lager som anropat DAL:et fånga denna exception och sedan bestämma vad som skall göras med den, är det en websida? Ja då öppnar vi vår speciella felsida, är det en winform? Ja då slänger vi upp en popup, är det en webservice? Ja då loggar vi felet till en databas och skickar iväg ett mail till sysadmin om felet... eller vad vi nu kan hitta på.

Generellt kan man säga så här. Alla din applikationer bygger på lager. UI->Business->DAL-DataStorage. Och man har bara beroende neråt i lagerna. Så UI känner till allt om Business, men Business vet inget om UI (den vet inte om det är en winform eller webform, och den bry sig inte heller) däremot så vet den allt om DAL (som UI inte vet något om, den känner bara till business) DAL:et vet inget om business inte heller om UI. Men däremot allt om din data som finns lagrad i din datastorage.

Så man har bara beroende på ETT håll... Aldrig Två!!! (det finns undantag, men det tar vi inte upp här, och det är väldigt väldigt sällan)...

- M

Höhö.. du har så rätt så rätt! Hur som helt så löste jag det på ett annat sätt som är kanske lite mer accepterat! :)

I DAL:et

public string SQLExec(string sSQL) {
// kod.. mera kod..
try {
// Tjoffsig kod...

} catch(SQLException ex) {

return "Fel: " + ex.Message.ToString();

}
// kod..

return ""; 
}

I Default.aspx

// kod.. 
string err = db.SQLExec(sSQL).ToString();

if(err.Length !=0) {
// kod..

ErrMsg.Text = err;

} else {
// kod.. 
}

Det funkade bättre.. och kan nog användas i ex winForm's med en popup också eller?

Japp det är mer korrekt (men ändå inte bra :)), när du gör så så omvandlar du hela ditt exceptions objekt till att endast bestå av felmeddelandet.

Det är okej om du inte är intresserad av den andra information eller om du spara ner den någon annanstans, eftersom det faktiskt är den informationen som oftas är intressant, den innerhåller ju faktiskt exakt var i koden som felet uppstod och vilka metoder som har kallats innan, och om det har funnits andra fel som detta fel har fångat.

Generellt så är du aldrig intresserad av ditt ytterstafels felmeddelande, utan ditt innersta fels felmeddelande eftersom det faktiskt är det som ger dig någon som helst ledtråd om vad som är fel. Nu är det generellt och jag vet många tillämpningar när man inte gör så och det med rätta...

Men gör dig inte av med exceptions objektet hur som helst, i mina felrutiner så spara jag ner all den information som finns i exceptions objektet tillsammans med en massa annan information om trådid, processerid, minnesförbrukning osv osv ner i databas, samt att jag loggar inte bara felet som jag fångar, utan alla fel som finns inne i detta fel också, det är guldvärt när man skall felsköka för applikationer som ligger i produktion och man inte bara kan återskapa felet hur som helst... mitt tips, logga allt och lite till....

- M

Måste bara säga till Gladh att det är oerhört intressant att läsa dina inlägg. Tummen upp! (y)

Gladh skrev:

Japp det är mer korrekt (men ändå inte bra :)), när du gör så så omvandlar du hela ditt exceptions objekt till att endast bestå av felmeddelandet.

Det är okej om du inte är intresserad av den andra information eller om du spara ner den någon annanstans, eftersom det faktiskt är den informationen som oftas är intressant, den innerhåller ju faktiskt exakt var i koden som felet uppstod och vilka metoder som har kallats innan, och om det har funnits andra fel som detta fel har fångat.

Generellt så är du aldrig intresserad av ditt ytterstafels felmeddelande, utan ditt innersta fels felmeddelande eftersom det faktiskt är det som ger dig någon som helst ledtråd om vad som är fel. Nu är det generellt och jag vet många tillämpningar när man inte gör så och det med rätta...

Men gör dig inte av med exceptions objektet hur som helst, i mina felrutiner så spara jag ner all den information som finns i exceptions objektet tillsammans med en massa annan information om trådid, processerid, minnesförbrukning osv osv ner i databas, samt att jag loggar inte bara felet som jag fångar, utan alla fel som finns inne i detta fel också, det är guldvärt när man skall felsköka för applikationer som ligger i produktion och man inte bara kan återskapa felet hur som helst... mitt tips, logga allt och lite till....

- M

Åh! Man tackar för det finna inlägget! :e

Skall labba lite med dessa exceptions! :)

Kolla på Enterprise Application Blocks, där finns ett logginblock som är mycket trevligt att norpa idér från. Kloka ord från Gladh som alltid. Det viktiga är att man har en hållbar strategi för felhantering, där det viktigaste ur ett utvecklarperspektiv är att kunna hitta varför felet uppstod, och ur ett användarperspektiv, förklara att något gick fel, inte mer. Många erbjuder gärna lite för mycket information till användaren om vad som gick fel, vare det är via ett application exception som spottas ut i browsern eller ett vältalande felmeddelande.

erka skrev:

viktigaste ur ett utvecklarperspektiv är att kunna hitta varför felet uppstod, och ur ett användarperspektiv, förklara att något gick fel, inte mer.

Japp, det är därför som det är bra att ha egan exceptions som man wrappar de som .net kastar iväg, för där kan du styra vilken information som skall stå i message fältet. Det kanske inte är så bra att visa alla felmeddelande från din databas direkt till slutanvändaren eftersom det kan innehålla information som du inte vill dela med dig.

Själv så brukar jag ha 2 olika bastyper av mitt eget exceptionobjekt. Det är technical och business. I den information som jag visar till användaren så kontrollerar jag om det är at typen technical och presenterar en generell text som säger att ett tekniskt fel har uppstått kontakta admin och lämna detta ID (id som kan plocka fram just det felet från databasen. Är exceptions av business typ så visas Messages-fältet eftersom det oftas är sådan fel som en användare har lyckas ställa till det med, (typ filen finns inte, eller det är fel url till tjänsten osv osv) och då ger man användaren en chans att rättat till felet och försöka igen...

- M