tack... det var de som var felet... men nu kom nästa fel:
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
Line 23:
Line 24: for (int i=0; i<navParent.Items.Count; i++) {
Line 25: ((Label) navParent.Items[i].FindControl("lblChild")).Text = "test";
Line 26: }
Line 27:
Source File: e:\web\wwwroot\webshop\nav.aspx Line: 25
Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
ASP.nav_aspx.Page_Load(Object sender, EventArgs e) in e:\web\wwwroot\webshop\nav.aspx:25
System.Web.UI.Control.OnLoad(EventArgs e) +67
System.Web.UI.Control.LoadRecursive() +29
System.Web.UI.Page.ProcessRequestMain() +724
eftersom jag är nybörjare på ASP.Net men har hållit på med ASP tidigare så skulle de vara treligt med mycke hjälp
Eftersom att jag inte programmerar i C# eller i .NET över huvud taget, så är jag inte säker på det jag skriver, men jag ser att du måste fånga ett exception som kastas.
try {
// Gör det du ska här
}
catch ( System.NullReferenceException e ) {
// Felhantering
}
I catch-blocket sköter du felhanteringen, om det blir något fel. Är det andra exceptions som ska fångas lägger du bara på ytterligare en catch-sats.
Jupp, try/catch är suveränt! Men det känns ändå lite som om det är en farlig genväg i programmering när man behöver nästla sig ur kod som ju faktiskt genererar fel? Jag använder det nog lite för ofta i alla fall... ibland skriver man kod där man medvetet returnerar fel i vissa situationer som man sedan catchar med annan kod. Vad säger alla duktiga programmerare om sånt egentligen? Exempelvis med tanke på prestanda/stabilitet/säkerhet? Eller tänker jag fel?
ibland skriver man kod där man medvetet returnerar fel
Varför?!
Jag är väl ingen suverän programmerare, men i Java som jag programmerar en del i har jag fått en del tips på hur man ska behandla exceptions, och att man ska göra det ofta.
Stabiliteten bör ju endast bli bättre, eftersom det är mindre risk att man förlorar kontrollen över sina applikationer - däremot prestandan vet jag inte... Den bör inte sänkas så mycket, eftersom att catch-blocken endast körs om det verkligen blir ett fel ( Om jag har förstått det rätt ) och då behövs de ju.
Du har din label i din footertemplate. En footertemplate körs ju bara EN gång till skillnad från din ItemTemplate som ju loopas för varje rad i ditt dataset och du försöker ju sätta texten för varje rad i ditt dataset med en for-sats (<navParent.Items.Count)! Om du hade din label i din ItemTemplate så skulle det nog fungera, men vill du ha den i din footertemplate så ska du bara sätta texten en gång.
SPiN: Ibland tycker jag det är lättare att fånga upp ett fel (istället för att alltid behandlla alla händelser korrekt) och sen catcha med kod som alltid fungerar. Jag är bara en glad amatör och då får man programmera dåligt.
================================
ibland skriver man kod där man medvetet returnerar fel
================================
Varför?!
Jag är väl ingen suverän programmerare, men i Java som jag programmerar en del i har jag fått en del tips på hur man ska behandla exceptions, och att man ska göra det ofta.
Det där är ju en avvägningsfråga. Eftersom ev. fel oftast påvisas i användargränssnittet är det inte så bra om man fångar varje undantag där det kan träffas och därifrån visar felmeddelande, så ibland är det bra att låta ett undantag att segla uppåt i hierarkin av anrop. Förr eller senare ska det förstås fångas, men det behöver inte vara så långt ner som möjligt...
271 ms totalt · 4 externa anrop · v20260731065814-full.d34c6d5a