Response.Redirect plus Response.End

I am reading code i don't fully understand, so i came to the conclusion that there is something i am missing or the code is just a mistake, and i would understand which of the two.

This is the code i don't understand :

this.Response.Redirect('url', false);
this.Response.End();

Isn't it equivalent to :

this.Response.Redirect('url');

if so why write two statement instead of one? I can't understand the pourpose of Response.End() and have the feeling that there is something i miss about the meaning of those commands.

this.Response.Redirect('url', false); --> Should redirect without terminating current thread
this.Response.Redirect('url', true); --> Should redirect, terminating current thread using a ThreadAbortException
this.Response.Redirect('url'); --> Should redirect, terminating current thread using a ThreadAbortException
this.Response.End(); --> Should terminate current thread using a ThreadAbortException, if this operation fail, then current response is flushed as is to client.

--EDIT : more context

As comment have pointed out is better if i add a bit of a context.
The project in which i find the code is an ASP.NET Web Form project. The code appear in the server side handler of a button click event (in the code bheind of the page, so in a aspx.cs).

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.

Ok, so basically you have two concepts there:

Response.Redirect('url', false) is a method that basically says: Redirect to a new page and do not end the connection. Redirect calls End which throws a ThreadAbortException exception upon completion if the second parameter is null or set to true. This exception has a detrimental effect on Web application performance.

Response.End()is a more "controlled" way to end the connection, a more in-depth explanation can be seen here. This can be used exclusively for compatibility with ASP, when it tries to mimic the behavior of the End method in ASP by raising a ThreadAbortException exception. If the End method is not able to raise this exception, it instead flushes the response bytes to the client. It does this synchronously, which can also be detrimental to your performance also.

So, it's not a common practice at all and I would classify that as a error if the objective was not to do compatibility with ASP.