error handling - Passing variables in classic ASP

Question

I am dealing with legacy code where there is an include of another ASP page.

<!--#INCLUDE virtual="/PAGE1.ASP"-->

to get a variable, say x, from that page, I beleive I would do:

x = Request.Form("x")

is that correct?

Also, are the variable names case sensitive for classic .ASP files?

Thanks so much.

Answer 1

You should think of the page as being built into one contiguous page, so that if you include a number of .asp files they will build up your finished page.

For instance, if you have three files:

File_1.asp

<h1>Hello, World!</h1>

File_2.asp

<p>This file will be included too!</p>

File_3.asp

<%Dim version
version = 1.1%>

...and include them in one core file...

File_Output.asp

<!-- #include virtual="file_1.asp" -->
<!-- #include virtual="file_2.asp" -->
<!-- #include virtual="file_3.asp" -->
<% Response.Write(version) %>

File_Output.asp will display the version variable defined in File_3.asp.

There's a nice little article about it here.

-- EDIT --

Just to add (having missed the question at the end of your post):

Case sensitivity depends on the scripting language used by Classic ASP. With VBScript variable names are case insensitive, whereas, with JScript (which, syntactically, is very much like JavaScript) variables are case sensitive.

Also, to address the Err object:

There's a great little piece here, but to get to the nitty-gritty, you need to wrap your code in an error catching block like so:

On Error Resume Next    '<-- This line starts trapping errors
    ...
On Error Goto 0         '<-- This line stops trapping errors

If an error does occur in this block you need to deal with it. Unlike ASP.NET, Java, etc. etc., you are not told that there is an error; there is no nice Try...Catch wrapper to handle the errors nicely. You must kind of predict where the error will happen. Usually it's obvious. If you have database manipulation in your script it's a good idea to test for errors directly after your data read or write. To check for errors is simple - you test the Number property of the Err object:

On Error Resume Next    '<-- This line starts trapping errors
    'Some database manipulation...
    If Err.Number <> 0 Then
        ... 'Handle the error
    End If
On Error Goto 0         '<-- This line stops trapping errors

This can be expanded to take into account different error messages:

On Error Resume Next    '<-- This line starts trapping errors
    'Some database manipulation...
    Select Case Err.Number
        Case 1
            ... 'Handle the error
        Case 2
            ...
        Case 3021 'No data returned
            Response.Write("No data was returned.")
    End Select
On Error Goto 0         '<-- This line stops trapping errors

Hope this helps.