Now having said all the problems with debug=true, I must say that there is a good side to debug=true as well. So, what do you actually lose by setting debug=false?
To show this I have added the following code in Page_Load method of Default.aspx. This code will cause an error message whenever you request the page.
Listing 9
Protected Sub Page_Load(ByVal sender As Object, _ ByVal e As System.EventArgs) Handles Me.Load Dim x As Integer x = 0 x = x / 0 End Sub
Check the output if you have debug="false" (first part of the code) and the same page with debug="true" (second half of the code) in Listing 10.
Listing 10 – Bad Code causing Overflow Exception
[OverflowException: Arithmetic operation resulted in an overflow.] _Default.Page_Load(Object sender, EventArgs e) +18 System.Web.UI.Control.OnLoad(EventArgs e) +99 System.Web.UI.Control.LoadRecursive() +47 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061
[OverflowException: Arithmetic operation resulted in an overflow.] _Default.Page_Load(Object sender, EventArgs e) in I:\My Documents\Visual Studio 2005\WebSites\DebugTrue\Default.aspx.vb:8 System.Web.UI.Control.OnLoad(EventArgs e) +99 System.Web.UI.Control.LoadRecursive() +47 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061
Notice that with debug=“true” you get a more detailed stack output and it even tells you that the problem happened on line number 8 in a page located at I:\My Documents\Visual Studio 2005\Websites\DebugTrue\Default.aspx.vb:8.
But, do you honestly think that getting this detailed error message with debug=true outweighs the performance gain with debug=false? If there is a scenario where you would answer YES, I would suggest you go ahead turn debug=“true,” fix your problem and turn debug=“false” back again.
User Comments