Debugging with Response.Write in classic ASP

问题:

I am trying to debug some code using Response.Write, but when I run the code it skips over that statement and errors out at some point further in the code.

How can I get my Response.Write statements to show without the other errors coming up?

回答1:

I quite frequently use Response.End when I have to see a status in a certain place on a page.

回答2:

We utilize Visual Studio 2008 to debug classic asp pages. You can attach to the IIS process and "step through" the page. Its very sweet. Here are the steps:

1. Get latest of the classic ASP from source control.

2. Install IIS (if not already). FYI... I am using IIS 5.1.

3. Create a virtual directory called "classicDebug" pointing to your local directory (C:\Websites\ClassicWebSite).

4. View the virtual directory properties, Virtual Directory tab.

5. Enable the "Script source access" checkbox.

6. Configuration button, Options tab - check everything.

7. Debugging tab - check everything.

   7a. In the ASP.NET tab, select 2.x

8. Load up (not run or debug or F5) the website in VS.NET 2008.

9. Edit your global.asa accordingly (data sources, and paths).

10. Find the .asp page you want to "step through" and set a break point at the top (or somewhere).

11. Open IE, and navigate to your page.

12. Go back to VS.NET and select Debug -> Attach to Process

13. Check "show processes from all users" and select the process. For me (IIS 5.1), the process name is dllhost.exe running with the IWAM_COMPUTERNAME account w/type "Script, T-SQL, Managed, x86".

14. Visit your page using IE... VS.NET should break.

回答3:

Comment out the line which gives the error and see what the respnse.write is displaying is the only thing reasonable.

Don't use the on error resume next while you are developing your pages. You have to make sure that you building your pages correctly and that your are producing correct code. You wont see any errors if you use on error resume next.

on error resume next should only be used, in my opinion, in database actions and in delivered (non-developning) code. In that case you should use the

if Err.Number <> 0 then 

construct to test any errors. You simply cannot do that after every line in asp if you have put the on error resume next statement at the top of your code, but it certainly makes sence in database handling code.

回答4:

You will have to use "on error resume next" statement on top of your ASP page. This will solve your problem when an error occurs it will move to next line rather than throwing an error.

You can check this link http://www.powerasp.com/content/new/on-error-resume-next.asp for reference.

Happy Coding

回答5:

Try a Response.Flush after your debugging statments, or setting Response.Buffer to false.

回答6:

This might help as an alternative to response.write.

I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.

https://github.com/dmeagor/ClassicASP-FirePHP

Just include the file and use log(somevalue) to send formatted variables to the firebug console.

Released under MIT open source license

回答7:

Speaking of alternate options, from David Meagor post, you can also write traces to a file. Here is an example of how to write to files: http://www.4guysfromrolla.com/webtech/040699-1.shtml

If you want, you can even put the trace subroutines in an include file and use that in all your pages when you need it.

Another solution that we are using is to put the tracing methods in a .Net assembly, register it as a COM then call it using CreateObject.

These options will let you keep your traces in a file that you can review later and share with other developers.

I personally use a mix of these approaches: I review log files, use breakpoints and even place from time to time a Response.Write.

One other thing: activate and review the IIS logs: they will often tell you on what line your page broke. You can read here how to enable or disable logs for classic ASP: https://technet.microsoft.com/en-us/library/hh831387.aspx.