Try...Catch...F inally not firing finally?

[David Lozzi]

Howdy,

I ran into a very interesting issue and I'm curios as to how this is suppose
to work. I am using Try...Catch...F inally statements for all database
connectivity in my ASP.NET 2.0 web application. I'm connecting to IBM's
Universe 10.2 using UniObjects.Net. Anyway, if the connection errors, the
Finally closes the connection. What I see happening is that the function in
the Finally statement either isn't running or doesn't apply what its suppose
to.

For example. Running Visual Studio 2005, I debug my web app and step through
a function that I am purposly erroring on. The session opens, then a command
errors out. In the Catch I am taking the ex.tostring and sending it to a
class function that I then email that to myself and then send the user to a
default error page using server.transfer ("page",fals e). After that function
runs, the debugger sends me back to the calling function, finishes the Catch
then fires the Finally, which closes the session.

So my problem is that it appears that the database session is not closing in
the finally. I just moved the close session to the first line in the Catch
and it appears to close it properly...

Thanks!!

David Lozzi

[Samuel R. Neff]

What exactly does the finally clause look like? Is it possible that
something within the finally clause is generating a second error
before the database "session" is closed (what do you mean exactly,
connection? if so use the using clause instead anyways).

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Mon, 23 Apr 2007 17:46:36 -0400, "David Lozzi"
<dl****@nospam. nospamwrote:

>Howdy,

I ran into a very interesting issue and I'm curios as to how this is suppose
to work. I am using Try...Catch...F inally statements for all database
connectivity in my ASP.NET 2.0 web application. I'm connecting to IBM's
Universe 10.2 using UniObjects.Net. Anyway, if the connection errors, the
Finally closes the connection. What I see happening is that the function in
the Finally statement either isn't running or doesn't apply what its suppose
to.

For example. Running Visual Studio 2005, I debug my web app and step through
a function that I am purposly erroring on. The session opens, then a command
errors out. In the Catch I am taking the ex.tostring and sending it to a
class function that I then email that to myself and then send the user to a
default error page using server.transfer ("page",fals e). After that function
runs, the debugger sends me back to the calling function, finishes the Catch
then fires the Finally, which closes the session.

So my problem is that it appears that the database session is not closing in
the finally. I just moved the close session to the first line in the Catch
and it appears to close it properly...

Thanks!!

David Lozzi

[bruce barker]

server transfer aborts the current thread, so the finally will not fire.
you should not call it in a catch statement.

-- bruce (sqlwork.com)

David Lozzi wrote:

Howdy,

I ran into a very interesting issue and I'm curios as to how this is
suppose to work. I am using Try...Catch...F inally statements for all
database connectivity in my ASP.NET 2.0 web application. I'm connecting
to IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection
errors, the Finally closes the connection. What I see happening is that
the function in the Finally statement either isn't running or doesn't
apply what its suppose to.

For example. Running Visual Studio 2005, I debug my web app and step
through a function that I am purposly erroring on. The session opens,
then a command errors out. In the Catch I am taking the ex.tostring and
sending it to a class function that I then email that to myself and then
send the user to a default error page using
server.transfer ("page",fals e). After that function runs, the debugger
sends me back to the calling function, finishes the Catch then fires the
Finally, which closes the session.

So my problem is that it appears that the database session is not
closing in the finally. I just moved the close session to the first line
in the Catch and it appears to close it properly...

Thanks!!

David Lozzi

[Samuel R. Neff]

Not true. The finally always runs.

protected void Page_Load(objec t sender, EventArgs e)
{
try
{
Log.Debug(this, "Throwing error...");
throw new Exception();
}
catch
{
Log.Debug(this, "Caught..") ;
Server.Transfer ("gateway.aspx" , false);
}
finally
{
Log.Debug(this, "Finally... ");
}
}
produced..

2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Throwing
error...
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Caught..
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Finally...

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 24 Apr 2007 08:49:33 -0700, bruce barker <no****@nospam. com>
wrote:

>server transfer aborts the current thread, so the finally will not fire.
you should not call it in a catch statement.

-- bruce (sqlwork.com)

[Alvin Bruney [MVP]]

The two conditions really aren't related - i don't think. Finally blocks
always fire, there's an implicit guarantee for that. True there was a bug in
1.1 that abrogated that guarantee, but it is fixed in 2.0. So the problem
would lie in the close code. It's quite possible that close is erroring out.
Put a trace from the db end to see if the close command is funneling thru to
the database engine.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C8******** *************** ***********@mic rosoft.com...

Howdy,

I ran into a very interesting issue and I'm curios as to how this is
suppose to work. I am using Try...Catch...F inally statements for all
database connectivity in my ASP.NET 2.0 web application. I'm connecting to
IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection
errors, the Finally closes the connection. What I see happening is that
the function in the Finally statement either isn't running or doesn't
apply what its suppose to.

For example. Running Visual Studio 2005, I debug my web app and step
through a function that I am purposly erroring on. The session opens, then
a command errors out. In the Catch I am taking the ex.tostring and sending
it to a class function that I then email that to myself and then send the
user to a default error page using server.transfer ("page",fals e). After
that function runs, the debugger sends me back to the calling function,
finishes the Catch then fires the Finally, which closes the session.

So my problem is that it appears that the database session is not closing
in the finally. I just moved the close session to the first line in the
Catch and it appears to close it properly...

Thanks!!

David Lozzi

[David Lozzi]

I ran a similar test instead used response.write( ) and it never reached the
finally........

"Samuel R. Neff" <sa********@nom ail.comwrote in message
news:dh******** *************** *********@4ax.c om...

>
Not true. The finally always runs.

protected void Page_Load(objec t sender, EventArgs e)
{
try
{
Log.Debug(this, "Throwing error...");
throw new Exception();
}
catch
{
Log.Debug(this, "Caught..") ;
Server.Transfer ("gateway.aspx" , false);
}
finally
{
Log.Debug(this, "Finally... ");
}
}
produced..

2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Throwing
error...
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Caught..
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Finally...

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 24 Apr 2007 08:49:33 -0700, bruce barker <no****@nospam. com>
wrote:

>>server transfer aborts the current thread, so the finally will not fire.
you should not call it in a catch statement.

-- bruce (sqlwork.com)

[David Lozzi]

I ran a test using response.write( ) in each section of the try, and it never
reached the finally........

And the close works fine, it calls a simple
UniObjects.Clos eSession(unises sion). And when I moved it to the first line
of the catch it works fine everytime. We had a trace running on the DB end
and it kept saying that the session was never closed, no other errors.
"Alvin Bruney [MVP]" <some guy without an email addresswrote in message
news:O0******** ******@TK2MSFTN GP03.phx.gbl...

The two conditions really aren't related - i don't think. Finally blocks
always fire, there's an implicit guarantee for that. True there was a bug
in 1.1 that abrogated that guarantee, but it is fixed in 2.0. So the
problem would lie in the close code. It's quite possible that close is
erroring out. Put a trace from the db end to see if the close command is
funneling thru to the database engine.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C8******** *************** ***********@mic rosoft.com...

>Howdy,

I ran into a very interesting issue and I'm curios as to how this is
suppose to work. I am using Try...Catch...F inally statements for all
database connectivity in my ASP.NET 2.0 web application. I'm connecting
to IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection
errors, the Finally closes the connection. What I see happening is that
the function in the Finally statement either isn't running or doesn't
apply what its suppose to.

For example. Running Visual Studio 2005, I debug my web app and step
through a function that I am purposly erroring on. The session opens,
then a command errors out. In the Catch I am taking the ex.tostring and
sending it to a class function that I then email that to myself and then
send the user to a default error page using
server.transfe r("page",false) . After that function runs, the debugger
sends me back to the calling function, finishes the Catch then fires the
Finally, which closes the session.

So my problem is that it appears that the database session is not closing
in the finally. I just moved the close session to the first line in the
Catch and it appears to close it properly...

Thanks!!

David Lozzi

[Alvin Bruney [MVP]]

Can you post a short sample application that demonstrates the problem, i'd
like to take a closer look.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C3******** *************** ***********@mic rosoft.com...

>I ran a test using response.write( ) in each section of the try, and it
never reached the finally........

And the close works fine, it calls a simple
UniObjects.Clos eSession(unises sion). And when I moved it to the first line
of the catch it works fine everytime. We had a trace running on the DB end
and it kept saying that the session was never closed, no other errors.
"Alvin Bruney [MVP]" <some guy without an email addresswrote in message
news:O0******** ******@TK2MSFTN GP03.phx.gbl...

>The two conditions really aren't related - i don't think. Finally blocks
always fire, there's an implicit guarantee for that. True there was a bug
in 1.1 that abrogated that guarantee, but it is fixed in 2.0. So the
problem would lie in the close code. It's quite possible that close is
erroring out. Put a trace from the db end to see if the close command is
funneling thru to the database engine.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C8******* *************** ************@mi crosoft.com...

>>Howdy,

I ran into a very interesting issue and I'm curios as to how this is
suppose to work. I am using Try...Catch...F inally statements for all
database connectivity in my ASP.NET 2.0 web application. I'm connecting
to IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection
errors, the Finally closes the connection. What I see happening is that
the function in the Finally statement either isn't running or doesn't
apply what its suppose to.

For example. Running Visual Studio 2005, I debug my web app and step
through a function that I am purposly erroring on. The session opens,
then a command errors out. In the Catch I am taking the ex.tostring and
sending it to a class function that I then email that to myself and then
send the user to a default error page using
server.transf er("page",false ). After that function runs, the debugger
sends me back to the calling function, finishes the Catch then fires the
Finally, which closes the session.

So my problem is that it appears that the database session is not
closing in the finally. I just moved the close session to the first line
in the Catch and it appears to close it properly...

Thanks!!

David Lozzi

[David Lozzi]

Sure, below. This is how it was, now the UOCloseSession function is before
the EmailError function.

Thanks!!
Public Function GetProduct(ByVa l strPartNo As String) As Boolean
Dim uniSession As UniSession = Nothing

Try
uniSession = UOOpenSession()

Dim unicom As UniCommand = uniSession.Crea teUniCommand
Dim subtext As String = ""
Dim qry As String = "LIST PARTS.WEB WITH @ID = " & strPartNo & "
DESC IMAGE DL.NOTES DISC_FLG GIFT_WRAP SIZEFLAG1 EXPECTED.DATE PRICE
MEDLEY_PARTS MEDLEY_IMAGES MEDLEY_STYLE PERSINSTR RELPARTS1 RELDESC1
PROD.TYPE TOXML ELEMENTS"
unicom.Command = qry
unicom.Execute( )
subtext = Mid(unicom.Resp onse, InStr(unicom.Re sponse, "<"),
Len(unicom.Resp onse))
unicom.Dispose( )

........ stuff .......
Catch ex As Exception
EmailError("pro duct_details.vb ", "GetProduct ", ex.ToString,
"Partno=" & strPartNo)
Return False
Finally
UOCloseSession( uniSession)
End Try
Public Shared Function UOCloseSession( ByRef unisess As UniSession)
UniObjects.Clos eSession(unises s)
End Function
Public Shared Function EmailError(ByVa l strPage As String, ByVal
strFunction As String, ByVal strError As String, Optional ByVal strOther As
String = "", Optional ByVal bolSend As Boolean = True, Optional ByVal
intLogType As Integer = 1)
If ConfigurationMa nager.AppSettin gs("ErrorEmailN otifications") =
True Then
If Not strError.Contai ns("viewstate MAC") Then
Dim msg As New MailMessage

msg.From = New
MailAddress(Con figurationManag er.AppSettings( "ErrorEmailFrom "))

Dim toEmails() As String =
ConfigurationMa nager.AppSettin gs("ErrorEmailT o").Split("; ")
For i As Integer = 0 To toEmails.Length - 1
msg.To.Add(toEm ails(i))
Next

msg.Subject = "Error on " &
Current.Request .ServerVariable s("SERVER_NAME" ) & " Website"
msg.IsBodyHtml = True
msg.Body = "<font face=verdana size='2'><b>Err or on " &
Current.Request .ServerVariable s("SERVER_NAME" ) & " Website!</b><br>" & Now()
& "<BR><br>" & _
"<b>Page Name:</b" & strPage & "<br>" & _
"<b>URL:</b>" &
Current.Request .ServerVariable s("URL") & "<br>" & _
"<b>Functio n Name:</b" & strFunction & "<br><br>"
& _
"<b>Error Message:</b" & strError & "<br><br>"

Dim smtpClient As New SmtpClient
smtpClient.Host = ConfigurationMa nager.AppSettin gs("SMTPServer" )
smtpClient.Send (msg)
Current.Applica tion("ErrorEmai l") = Nothing
End If
Else
If Current.Applica tion("ErrorEmai l") Is Nothing Then
Dim msg As New MailMessage

msg.From = New
MailAddress(Con figurationManag er.AppSettings( "ErrorEmailFrom "))

Dim toEmails() As String =
ConfigurationMa nager.AppSettin gs("ErrorEmailT o").Split("; ")
For i As Integer = 0 To toEmails.Length - 1
msg.To.Add(toEm ails(i))
Next

msg.Subject = "Errors are disabled on " & WebsiteName & "
Website"
msg.IsBodyHtml = True
msg.Body = "<font face=verdana size='2'><b>Err or
notification is disabled on " & WebsiteName & " however an error occured!"

Dim smtpClient As New SmtpClient
smtpClient.Host =
ConfigurationMa nager.AppSettin gs("SMTPServer" )
smtpClient.Send (msg)
Current.Applica tion("ErrorEmai l") = "done"
End If
End If

If bolSend Then
Current.Server. Transfer("~/oops.aspx", False)
End If

Return True
End Function
"Alvin Bruney [MVP]" <some guy without an email addresswrote in message
news:eK******** ******@TK2MSFTN GP05.phx.gbl...

Can you post a short sample application that demonstrates the problem, i'd
like to take a closer look.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C3******** *************** ***********@mic rosoft.com...

>>I ran a test using response.write( ) in each section of the try, and it
never reached the finally........

And the close works fine, it calls a simple
UniObjects.Clo seSession(unise ssion). And when I moved it to the first
line of the catch it works fine everytime. We had a trace running on the
DB end and it kept saying that the session was never closed, no other
errors.
"Alvin Bruney [MVP]" <some guy without an email addresswrote in message
news:O0******* *******@TK2MSFT NGP03.phx.gbl.. .

>>The two conditions really aren't related - i don't think. Finally blocks
always fire, there's an implicit guarantee for that. True there was a
bug in 1.1 that abrogated that guarantee, but it is fixed in 2.0. So the
problem would lie in the close code. It's quite possible that close is
erroring out. Put a trace from the db end to see if the close command is
funneling thru to the database engine.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professiona l VSTO 2005 - Wrox/Wiley
"David Lozzi" <dl****@nospam. nospamwrote in message
news:C8****** *************** *************@m icrosoft.com...
Howdy,

I ran into a very interesting issue and I'm curios as to how this is
suppose to work. I am using Try...Catch...F inally statements for all
database connectivity in my ASP.NET 2.0 web application. I'm connecting
to IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection
errors, the Finally closes the connection. What I see happening is that
the function in the Finally statement either isn't running or doesn't
apply what its suppose to.

For example. Running Visual Studio 2005, I debug my web app and step
through a function that I am purposly erroring on. The session opens,
then a command errors out. In the Catch I am taking the ex.tostring and
sending it to a class function that I then email that to myself and
then send the user to a default error page using
server.trans fer("page",fals e). After that function runs, the debugger
sends me back to the calling function, finishes the Catch then fires
the Finally, which closes the session.

So my problem is that it appears that the database session is not
closing in the finally. I just moved the close session to the first
line in the Catch and it appears to close it properly...

Thanks!!

David Lozzi

[Samuel R. Neff]

Have to be careful that the test is really testing what you think it
is. Testing with Response.Write( ) will test not only that the finally
is reached but also that the Response stream is still valid at that
point, which it isn't.

HTH,

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Mon, 7 May 2007 15:55:18 -0400, "David Lozzi"
<dl****@nospam. nospamwrote:

>I ran a similar test instead used response.write( ) and it never reached the
finally....... .

"Samuel R. Neff" <sa********@nom ail.comwrote in message
news:dh******* *************** **********@4ax. com...

>>
Not true. The finally always runs.

protected void Page_Load(objec t sender, EventArgs e)
{
try
{
Log.Debug(this , "Throwing error...");
throw new Exception();
}
catch
{
Log.Debug(this , "Caught..") ;
Server.Transfe r("gateway.aspx ", false);
}
finally
{
Log.Debug(this , "Finally... ");
}
}
produced..

2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Throwing
error...
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Caught..
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_asp x - Finally...

Sam