Exceptions thrown in includes not caught

[Martin Plechsmid]

Hello.

I've got IIS5, both at work and in my home, and I use JScript as the primary
scripting language in ASP.

When a function is defined in an included file, say

inc_dosth.asp:
<SCRIPT runat=server language=JScript>
function DoSth () {
throw new Error(0xFFFFFFFF);
}
</SCRIPT>

and called from within the ASP page body, say

test.asp:
<%@ LANGUAGE=JScript %>
<!-- #include file="inc_dosth.asp" -->
<%
try {
DoSth();
} catch (e) {Response.Write(e.description);}
%>

the try...catch clause should catch the exception. At my computer in my work
(Win2000 SP3, many Windows Update patches) this really works as expected.
However at home (Win2000 SP2, now SP4 (yes, SP4), no Windows Update
patches), these execeptions are caught by IIS and reported as unhandled
exceptions. On the exactly same code.

I hoped that the SP4 would repair the bug, but it haven't. What IIS patch do
I have to apply to get it working correctly at home too?

Thanks,
Martin.

 

[Mosley]

Hello.

**** knows,

but have you tried using a try catch with a different object and see if it
catches those exceptions?

then we will know if it is the object or for some reason try catch dont
work.

thats a start

 

[Martin Plechsmid]

I don't think that this problem is related to the order of execution. The
code in the includes contains function definitions only. It is surely
compiled, otherwise I wouldn't be able to execute the functions - and
nothing more than the compilation is needed.

Martin.

 

[Dave Anderson]

I don't think that this problem is related to the order of
execution.

You don't think so? Have you tried verifying it?


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Martin Plechsmid]

You don't think so? Have you tried verifying it?

The code below writes CYZBAX, as expected. There's nothing mysterious about
the execution order in ASP pages:
1. everything is included and compiled
2. code in <%...%> is executed in the definition order
3. code in <SCRIPT>...</SCRIPT> is executed in the definition order.
(In global.asa, the order is similar, only <%...%> are prohibitted.)

test.asp:
<%@ LANGUAGE=JScript LCID=1029 %>
<!-- #include file="inc_test.asp" -->
<SCRIPT LANGUAGE="JScript" RUNAT=Server>
Response.Write("X");

function DoY () {
Response.Write("Y");
}
</SCRIPT>
<%
Response.Write("Z");
DoB();
%>

inc_test.asp:
<SCRIPT LANGUAGE="JScript" RUNAT=Server>
Response.Write("A");

function DoB () {
Response.Write("B");
}
</SCRIPT>
<%
Response.Write("C");
DoY();
%>

I still don't see, how this could be related to try...catch. Can you be more
precise?

Martin.

 

[Dave Anderson]

So you're saying you have not verified it. I guess there's no point in
making a suggestion if you'll disregard it without trying it out.

FWIW, you're throwing an error, but not a description. What happens when you
use the following?

throw new Error(0xFFFFFFFF,"This is an error")

Any different?

The code below writes CYZBAX, as expected. There's nothing mysterious about
the execution order in ASP pages:
1. everything is included and compiled
2. code in <%...%> is executed in the definition order
3. code in <SCRIPT>...</SCRIPT> is executed in the definition order.
(In global.asa, the order is similar, only <%...%> are prohibitted.)

test.asp:
<%@ LANGUAGE=JScript LCID=1029 %>
<!-- #include file="inc_test.asp" -->
<SCRIPT LANGUAGE="JScript" RUNAT=Server>
Response.Write("X");

function DoY () {
Response.Write("Y");
}
</SCRIPT>
<%
Response.Write("Z");
DoB();
%>

inc_test.asp:
<SCRIPT LANGUAGE="JScript" RUNAT=Server>
Response.Write("A");

function DoB () {
Response.Write("B");
}
</SCRIPT>
<%
Response.Write("C");
DoY();
%>

I still don't see, how this could be related to try...catch. Can you be more
precise?

Will it matter? You don't seem willing to try it out anyway.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Martin Plechsmid]

So you're saying you have not verified it. I guess there's no point in

making a suggestion if you'll disregard it without trying it out.

I have verified it, CYZBAX is the magic word both at work and at home.

FWIW, you're throwing an error, but not a description. What happens when you
use the following?

throw new Error(0xFFFFFFFF,"This is an error")

Any different?

Still the same.

Thanks,

Martin.

 

[Martin Plechsmid]

There's one difference betwwen the machines: at work I use IE6, at home IE5,
but this is the difference I'd like to keep (for SW testing purposes). What
does IE and IIS have in common? The scripting engine. Maybe upgrading the
scripting engine would help, but this would be almost the same as upgrading
the IE. I'll try to make a save point, try it and roll back.

Any other idea that would influence IIS only?

Martin.

 

[Martin Plechsmid]

Installing the latest scripting engine (v.5.6) solved the problem.

Martin.

 

[Evertjan.]

Martin Plechsmid wrote on 07 jul 2003 in
microsoft.public.inetserver.asp.general:

I've got IIS5, both at work and in my home, and I use JScript as the
primary scripting language in ASP.

When a function is defined in an included file, say

inc_dosth.asp:
<SCRIPT runat=server language=JScript>
function DoSth () {
throw new Error(0xFFFFFFFF);
}
</SCRIPT>

and called from within the ASP page body, say

test.asp:
<%@ LANGUAGE=JScript %>
<!-- #include file="inc_dosth.asp" -->
<%
try {
DoSth();
} catch (e) {Response.Write(e.description);}
%>

This works when you change:

throw new Error(0xFFFFFFFF);

to

throw "MyError";

and

Response.Write(e.description)

to

Response.Write(e)