the simple matter is YES this is quite much the same thing:
this.Response.Redirect('url', false);
this.Response.End();
as this:
this.Response.Redirect('url');
or
this.Response.Redirect('url',true);
So, why write both when they do the same?
Well, the issue is NOT WHEN they do the same, but WHEN YOU want to do something different!!!!
I mean take this example:
void funtest()
{
// some code here
return;
}
or
void funtest()
{
// some code here
}
So, why bother with "return" WHEN they both do the same thing?
Answer: You might NOT want to do the same thing!!!!
So, you might do this:
void funtest()
{
if (some code condition)
return; // bail out, don't run the code that follows
// some code here
}
So, while the first example would be silly, since we don't care nor need the return statement, but in the 2nd case, WOW, time to call momma, it makes a HUGE difference.
So, just like the return statement "often" (most of the time) is NOT required, there are some VERY good use cases in which in your code YOU DO want to return, and thus as a developer, you can and would and should use the return statement. Use of the "return" statement gives you MUCH MORE control when that routine will exit.
100% same goes for the Response.End().
In most cases, just like you don't care nor need a return statement to end the code routine, sometimes YOU DO want that control of the code, and thus use the "return" statement.
And thus the same goes for Response.End(). It gives you the developer more control.
So, say this:
void funtest()
{
Response.Write("Hello how are you");
}
or
void funtest()
{
Response.Write("Hello how are you");
Response.End();
}
Now, if you calling JUST the one above routine and you happy the web page is NOW to be sent to the client side (Response.End() will SEND the web page to the client, and terminal any more running code).
So, in many ways, the Response.End() is MUCH like the return statement. Most of the time, don't care, don't worry, don't need.
However, there ARE times when you want to control the "return", so, you use the return statement and force the issue. It also makes your intention as a developer VERY clear.
Same goes for using Response.End(), it in effect is your "please send the browser copy back to the client" - we are done on the server, and I don't want anything more to occur on the server side.
The key concept is NOT WHEN the 2 code examples do the same thing, but WHEN YOU want to do something different here!!!
I mean, we can use
i = i + 1;
or
i++;
So, why have 2 ways of doing the same thing?
Well, WHEN YOU want to do something different.
So
i = i + 100;
Well, with i++, NOW that only adds 1, and that's not what I want to do!!!
So, comparing 2 parts of code that does the same thing, be it adding + 1, or above? Makes ZERO sense to compare 2 cases WHEN they do the same thing.
But, WHEN we want different behavior's ? Now we are talking!!!!
In other words, don't post 2 code examples that do the same thing (like adding + 1 to a value), and then ask why choose one or the other?
Answer: it probably don't matter much!!
however, WHEN you want different behavior's, THEN we have a reason and story for the 2 different approaches.
You can have "many" Response.Write("some text") in your code, but only AFTER ALL CODE is done, does the page travel back to the user desktop and display + render.
As you build up and use Response.Write("some txt"), the end user will not see ANY of those response.Writes UNTILL ALL of the page code is 100% done running,, and the IIS server releases that web page and sends back to the client.
So, Response.End() forces and allows you control when the page is "done" and to be "sent".
Same goes for this:
protected void Button1_Click(object sender, EventArgs e)
{
Response.Redirect("~/Test/StepProcess.aspx",false);
System.Threading.Thread.Sleep(5000);
}
So, the server will redirect to the other page, but ONLY AFTER your code that follows is complete!!!
So, in 99% of cases, when you do a Response.Redirect("some page"), you probably in 99% of cases want the current code to stop running!
but, as above shows? The response.redirect DOES NOT occur until all of the current code is done! (the page load event of the other page will not start until such time all code in the current page is 100% complete and has "exit" or in fact "returned". in above, that means the code will wait 5 seconds, AND THEN do the response.redirect.
So, just keep in mind that "Response.Write", Response.Redirect() etc is ONLY really going to update the current copy of the web page on the server that is being processed. You ONLY see the results of "writing" to the web page WHEN the page travels back to the client side (and that includes Response.Write().
Remember, Response.Write() INJECTS code in the browser to jump to the other page!!!
Ok, can we jump to another page and NOT use the Response.Write approach?
yes, you can do a server side re-direct to another page.
eg:
Server.TransferRequest("~/Test/StepProcess.aspx");
In above, the browser page is NOT sent to the client side, but in fact the server now jumps to the other web page. (but, it still going to run that 2nd line of code, and still wait until the code in current page is done running).
In above, this also means that no say JavaScript or any code in the current page will ever get a chance to run, since the current page WILL NOT be sent back to the client side.
You often in many cases need to control WHEN that page is 100% done, and will THEN be sent to the client side.
thus, in most cases, you don't care or worry about a Response.End(), but in some cases, you most certainly do want to control WHEN all the code stops, and the page is to be sent to the client side.
So, the issue is not WHEN the code does the same thing, it when YOU want something different to occur!!! Be it adding +1 with "++" or using Response.Redirect(), the issue not when they do the same thing, but when you want to control and have DIFFERENT behavior's is the REASON to use one or the other.
