Use Try ... in enterprise development. Catch... Will it affect efficiency?

Remember not long ago, a colleague of the company once said: "If the WinForm is developed, because the program is local, use Try ... Catch does not have much performance problems, but if it is on a Web server, try ... is not recommended. Catch... , because this can have a significant impact on the performance of the Web server. I had doubts about it at the time, because I didn't test it and I don't know if it was. So I did not declare my position at that time. First I searched through Google, with the same idea or the same question of a few people, the expression of personal views of all kinds of people have. But from my own subjective conclusion, subjective inference concludes that Try...catch does not affect program performance without throwing an exception, and does not necessarily become a performance bottleneck even if it affects performance.

What is the outcome? or write the code to do the test. Class using System used for testing;
Using System.Diagnostics;
Namespace WebApplication3
{
public static Class Test
{
public static void Notry ()
{
for (int i = 0; I < 10000 i + +)
{
System.Web.HttpContext.Current.Response.Write (i.ToString ());
}
}

public static void Havetry ()
{
Try
{
for (int i = 0; I < 10000 i + +)
{
System.Web.HttpContext.Current.Response.Write (i.ToString ());
}
}
catch (Exception err)
{
System.Web.HttpContext.Current.Response.Write (Err. ToString ());
}

}

public static long Haveexception ()
{
stopwatch SW = new Stopwatch ();
Sw. Start ();
Try
{
for (int i = 0; I < 10000 i + +)
{
System.Web.HttpContext.Current.Response.Write (i.ToString ());
}
throw new Exception ("Kevin makes me Abnormal");
}
catch (Exception err)
{
System.Web.HttpContext.Current.Response.Write (Err. ToString ());
}
Sw. Stop ();
return SW. Elapsedmilliseconds;
}
}
}
The code using System for the test page;
Using System.Diagnostics;

Namespace WebApplication3
{
public partial class _default:system.web.ui.page
{
protected void Page_Load (object sender, EventArgs e)
{

}

protected void Button1_Click (object sender, EventArgs e)
{
stopwatch SW = new Stopwatch ();
Sw. Start ();
Test.notry ();
Sw. Stop ();
Lblmessage.text = "Total elapsed time (in milliseconds) of the measurement instance:" + SW. Elapsedmilliseconds;
}

protected void button2_click (object sender, EventArgs e)
{
stopwatch SW = new Stopwatch ();
Sw. Start ();
Test.notry ();
Sw. Stop ();
Lblmessage.text = "Total elapsed time (in milliseconds) of the measurement instance:" + SW. Elapsedmilliseconds;
}

protected void Button3_Click (object sender, EventArgs e)
{
Lblmessage.text = Test.haveexception (). ToString ();
}
}
}

The test results are shown in the following table:

Group Times	Not using Try ... Catch... The time (in milliseconds)	Use Try ... Catch... But the time that the exception was not present (in milliseconds)	Use Try ... Catch... The time that the exception occurred (in milliseconds)
1	6	3	4
2	11	5	6
3	4	3	6
4	8	10	4
5	6	3	6
6	8	6	4
7	9	5	9
8	5	5	5
9	7	6	10
10	5	4	8
Average Time	6.9	5	6.2

By observing the test results, it was expected to be mixed with some surprises.

Accidentally, use a try ... Catch does not appear with exceptions and use Try ... Catch... The average execution time for an exception is greater than not using try ... Catch... The average execution time is short. It reminds me of a similar scene that happened a long time ago:

I've always thought that using a transaction in SQL Server is a lot slower than not using a transaction, but after testing, using a transaction is a lot faster than not using a transaction, and it's not an order of magnitude. As a result, using transactions becomes a means of improving database access performance.

Conclusion: Whatever development is done using C #, use Try ... Catch will not affect performance, but will slightly improve performance. Try ... Catch is not only used in development, but must be used in public methods of public classes, otherwise an exception can affect all users who call this method together. If you do not deal with the exception in the program for the sake of so-called performance, you cannot, in principle, pass (principle).

I used the VS2008+SP1 development environment to do a simple demo, interested friends can download the code to test their own.