Page 2 - Debugging techniques

When an asp page got an error it’s created an Err object, that returns the error, its description, etc. Like Err.Number, Err.Description…. right?

But that only returns the last occurred error and I wish to get all the occurred errors on the page and not only the last one.

Anyone knows how to do it?



Thanks in advance

Phoenix can u post a link which explain the method u have discussed with us.

Thanks.

It would be great if someone could post a simple step by step approach to configure Visual Studio to be used as a debugger for ASP pages whilst stepping through an ASP page line by line. i.e. As you can when you create a visual basic program and press F8 to enter and step line by line.

I suspect this isn't too easy to explain nor easy to set up but if someone has the time that would be extremely helpful.

Just ensure the IIS worker process holding the ASP page is currently running, open up the script in VS and attach to the worker process via Debug > Processes > %computerName% > %workerProcessNameForYourOs%

The running script should then appear in the "Running Documents" pallete.

One thing we did in Javascript at uni was to have if error <> 0 Then...
If Verror <> xyz then...
go to error handler

Set Verror at the top in a css or include file so you can test the whole site. When finished simple change Verror to something other than xyz and it will not show up!

hello people. im new to this forum and im a first time user of ASP. im finding so many problems with the programming. firstly, i keep getting system error messages wen the debugging begins and over 100 erros occur. i have used html in coding which works until it is debugged. plzzz help any1

First of all welcome to the forum....

If you want to get help with your coding, can you post a new
thread, rather than replying to this one as it is a completely new
topic.

Typically we need to see various things and if they are not there,
we will waste time asking for them

We need to know what you are trying to do,
We need to know what is actually happening.
We need to see the code that you are running - please
enclose it in blocks as it is a lot
easier to read.
Please also give us an exact error message and shown in your
code, the line where it is occuring.

i find that most errors, apart from basics are from database related.

now the best way to handle all database is to have a function for each database routine. ie connection, recordset, insert, updating, deleting etc.

now below is some code, that can be placed with the opening of database functions, or within the functions that deal with sql.



now this is one code, on one page and is included in all pages that require a database. the above method can be used for a whole page too, on error resume next is used. write your function and clear errors at begining

count if there is any errors in that function and deal with.


In the error code above, i redirected to an adminerror page.
if your database isent working you need to know, this page would be a page that takes the info from the url, then sends an email to you, the site owner.

you can then show your visiter a more friendly error page, and inform them that you have been informed about the problem.

another example of this, when we code we tend to try sonething

If okay Then
we display
Else
we give error
end if

however on error resume next we miss all that, unless there is a major problem. by starting with no errors. ie err = 0

then in our if we can have err = err & message

continue on

then we can great a count of all these errors on our page, and great a looping statements of all the errors found

IRT the rest of the forum: Yes, I'm still very much alive, although I don't lurk here anymore, but if anyone wants to call on WebStandardsMan, send me a PM.

We're on the *** end of a (roughly) 10,000 line ASP application right now, and our error-catching technique is almost exactly the one mentioned on the first page:

We set an application variable (named "bDebug" in our case) to "TRUE". In our main functions file is a function named "abug()" that takes 2 arguments - the status text to add to our debug string (page-scope variable), and a colour code to identify the type of status code it is (for example, green might be a "found item in loop" message, yellow might be an SQL statement, purple might be a success message of some kind, etc). Then anywhere we want feedback from our code we just call the function instead of using response.write. And if "bDebug" is TRUE, the debug code is displayed beneath the rest of the page.

Nine times out of ten, if a bug pops up, we can track down exactly where it is just by checking the last status message. It's a good idea to include things like function names in those status messages too - definitely makes it easier when you have a large application and any given page could generate a couple hundred status lines.

In our current application, now that we're near the end, we're adding an actual error-handling class that will log error messages and line numbers to a database (or to a file if the database fails, or an email if that fails, or it'll just give up and cry if nothing else works). All we need to do is modify our existing "abug" function to recognize an extra status code, and write those specific messages to the database.

Dynamic apps with lots of includes and/or using multiple languages can be a bear to debug... especially when client-side script errors crop up in ASP pages, since the line numbers in the error messages are usually wrong.

For client-side errors, I view the browser's page source to get the rendered html, save as Test.html, then wherever there's a client-side include (external js files, etc.), remove the include reference and copy the content of the include file in it's place - moving all of the code into the one page. This way, when viewing the Test.html, client-side error message line numbers will be correct.

For database errors, I find that error messages are usually much clearer in Query Analyzer (or the database front-end of choice). I print the actual statement being passed to the database using Response.Write, copy & run in Query Analyzer for clear error messages with approximate line numbers.

For sessions and other server-side data, I keep a global debug constant. By just setting the constant to true/false, each page will execute a global function that conditionally prints all session variables, etc. at the bottom of the page.

I agree with the response.write/response.end comments. I got fed up of writing the whole thing out though so went for a lazy function, seems daft, but I use it all the time now (tells you about my code huh!)

Sub print(print_string,quit)
response.write print_string & "<br>"
if quit<>0 then
response.End()
end if
End sub