Last post Jul 18, 2006 10:14 PM by smartwebagent
Jun 28, 2005 03:03 AM|dha80|LINK
This is my code:
mid = Int32.Parse(Request.Params("mid"))
mid = Null.NullInteger()
ContentId = Int32.Parse(Request.Params("ContentId"))
ContentId = Null.NullInteger()
Version = Int32.Parse(Request.Params("Version"))
Version = Null.NullInteger()
Response.Redirect(NavigateURL(TabId, "Edit", "mid=" & mid, "Action=" & NavigateCodes.AuthorList)) 'Error here
Jun 28, 2005 03:35 AM|steve.fabian|LINK
Jun 28, 2005 04:08 AM|dha80|LINK
Thank you very for you help, Fabian.
Jun 28, 2005 04:19 AM|hmnguyen|LINK
Jun 28, 2005 04:26 AM|Nocturnal|LINK
Jun 28, 2005 05:41 AM|dha80|LINK
Jun 28, 2005 07:41 AM|Nocturnal|LINK
Jun 28, 2005 12:24 PM|steve.fabian|LINK
Jun 28, 2005 01:27 PM|stevedotnut|LINK
Jul 18, 2006 10:14 PM|smartwebagent|LINK
I do not want to disagree entirely, but I think it is fair to say that the error "Object reference not set to an instance of an object" could have several causes.
For example, consider this:
//Assumed ASP.NET 1.0/1.1/2.0 web page name for this example = createnewproject.aspx
System.Boolean Boolean_TransactionSuccessful = false;
//do something (anything)
//provided all went well (doing something above) eventually the code will execute the below statement
Boolean_TransactionSuccessful = true;
throw new System.Exception(Exception_Error.Message.ToString());
if (Boolean_TransactionSuccessful == true )
This code works fine even though the code is redirecting within a TryCatchFinally block of code. Granted the code works only if the Response.Redirect("projectinformation.aspx") is located within the Finally block. The code will
throw an exception reading "Thread was being aborted" if the Response.Redirect("projectinformation.aspx") code was located within the Try block.
That said, even with this exact code was in place I have received the exception "Object reference not set to an instance of an object.". After tracking down the error, I discovered that it had nothing to do with the fact that I
had a Response.Redirect("projectinformation.aspx") entry in the Finally block and everything to do with the fact that once the page, projectinformation.aspx, started running it required a Session variable exist that had not been set. What had happened in
my case was that I had set a Session variable on another page called projectlookup.aspx which also redirects to projectinformation.aspx, but this time when I was debugging the application I was bypassing the projectlookup.aspx page and going to another page,
createnewproject.aspx, and then after successfully executing the code in the Try block I was coming to the Finally block and redirecting to the projectinformation.aspx page (AS SHOWN IN CODE ABOVE) but was doing so without setting the Session variable that
the projectlookup.aspx page usually set and that the projectinformation.aspx page was looking for. The compiler upon finding a null value for the Session variable when executing the projectinformation.aspx page rightfully threw the exception "Object reference
not set to an instance of an object.".
The moral of the story is that until you place a breakpoint at the beginning of every Catch block in every Class/Page involved in the scenario and debug step-by-step using F11 then you really can't just assume that relocating the
Response.Redirect outside of the TryCatchFinally blocks will rid you of the exception "Object reference not set to an instance of an object.".
Sure, the compiler could have more clearly stated the error to me by explaining to me what exact object (i.e. the named Session variable object) contained a null value instead of displaying the rather cryptic message stating "Object
reference not set to an instance of an object." as this error message doesn't help the programmer to understand what object wasn't set nor does it help to understand what line number in what code file did the error occur in. Time will result in more understandable
and useful compiler error messages...until then at least we've got Step-by-Step debugging.
I am entering these comments in hope that these comments help someone out there to realize that they need to check their code like I did to reveal the actual error instead of just blaming Microsoft's .NET v1.0/1.1/2.0 compiler(s)
of having a bug. I hate having to admit that the code I wrote has a bug, but I must admit that sometimes the code I write has bugs which is why I relentlessly debug and test over and over again prior to going to placing code in a Production environment.