Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Try...Catch...Finally not firing finally?

Reply
Thread Tools

Try...Catch...Finally not firing finally?

 
 
David Lozzi
Guest
Posts: n/a
 
      04-23-2007
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...Finally 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",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

 
Reply With Quote
 
 
 
 
Samuel R. Neff
Guest
Posts: n/a
 
      04-24-2007

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"
<(E-Mail Removed)> 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...Finally 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",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


 
Reply With Quote
 
 
 
 
bruce barker
Guest
Posts: n/a
 
      04-24-2007
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...Finally 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",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

 
Reply With Quote
 
Samuel R. Neff
Guest
Posts: n/a
 
      04-24-2007

Not true. The finally always runs.

protected void Page_Load(object 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_aspx - Throwing
error...
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - Caught..
2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - 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 <(E-Mail Removed)>
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)
>
>
>

 
Reply With Quote
 
Alvin Bruney [MVP]
Guest
Posts: n/a
 
      04-25-2007
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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...Finally 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",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



 
Reply With Quote
 
David Lozzi
Guest
Posts: n/a
 
      05-07-2007
I ran a similar test instead used response.write() and it never reached the
finally........



"Samuel R. Neff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Not true. The finally always runs.
>
> protected void Page_Load(object 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_aspx - Throwing
> error...
> 2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - Caught..
> 2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - 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 <(E-Mail Removed)>
> 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)
>>
>>
>>


 
Reply With Quote
 
David Lozzi
Guest
Posts: n/a
 
      05-07-2007
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.CloseSession(unisession). 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 address> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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...Finally 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",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

>
>


 
Reply With Quote
 
Alvin Bruney [MVP]
Guest
Posts: n/a
 
      05-07-2007
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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.CloseSession(unisession). 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 address> wrote in message
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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...Finally 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",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

>>
>>

>



 
Reply With Quote
 
David Lozzi
Guest
Posts: n/a
 
      05-08-2007
Sure, below. This is how it was, now the UOCloseSession function is before
the EmailError function.

Thanks!!


Public Function GetProduct(ByVal strPartNo As String) As Boolean
Dim uniSession As UniSession = Nothing

Try
uniSession = UOOpenSession()

Dim unicom As UniCommand = uniSession.CreateUniCommand
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.Response, InStr(unicom.Response, "<"),
Len(unicom.Response))
unicom.Dispose()

........ stuff .......
Catch ex As Exception
EmailError("product_details.vb", "GetProduct", ex.ToString,
"Partno=" & strPartNo)
Return False
Finally
UOCloseSession(uniSession)
End Try


Public Shared Function UOCloseSession(ByRef unisess As UniSession)
UniObjects.CloseSession(unisess)
End Function


Public Shared Function EmailError(ByVal 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 ConfigurationManager.AppSettings("ErrorEmailNotifi cations") =
True Then
If Not strError.Contains("viewstate MAC") Then
Dim msg As New MailMessage

msg.From = New
MailAddress(ConfigurationManager.AppSettings("Erro rEmailFrom"))

Dim toEmails() As String =
ConfigurationManager.AppSettings("ErrorEmailTo").S plit(";")
For i As Integer = 0 To toEmails.Length - 1
msg.To.Add(toEmails(i))
Next

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

Dim smtpClient As New SmtpClient
smtpClient.Host = ConfigurationManager.AppSettings("SMTPServer")
smtpClient.Send(msg)
Current.Application("ErrorEmail") = Nothing
End If
Else
If Current.Application("ErrorEmail") Is Nothing Then
Dim msg As New MailMessage

msg.From = New
MailAddress(ConfigurationManager.AppSettings("Erro rEmailFrom"))

Dim toEmails() As String =
ConfigurationManager.AppSettings("ErrorEmailTo").S plit(";")
For i As Integer = 0 To toEmails.Length - 1
msg.To.Add(toEmails(i))
Next

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

Dim smtpClient As New SmtpClient
smtpClient.Host =
ConfigurationManager.AppSettings("SMTPServer")
smtpClient.Send(msg)
Current.Application("ErrorEmail") = "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 address> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>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.CloseSession(unisession). 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 address> wrote in message
>> news:(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> 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...Finally 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",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
>>>
>>>

>>

>
>


 
Reply With Quote
 
Samuel R. Neff
Guest
Posts: n/a
 
      05-08-2007

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"
<(E-Mail Removed)> wrote:

>I ran a similar test instead used response.write() and it never reached the
>finally........
>
>
>
>"Samuel R. Neff" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>>
>> Not true. The finally always runs.
>>
>> protected void Page_Load(object 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_aspx - Throwing
>> error...
>> 2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - Caught..
>> 2007-04-24 12:22:46.98 [2276] DEBUG ASP.default_aspx - Finally...
>>
>> Sam
>>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
master page does not change due to preinit event not firing franchise63 General Computer Support 0 02-13-2008 09:18 AM
DataGrid ItemCommand event not firing if not first page =?Utf-8?B?ZGFuYw==?= ASP .Net 3 10-26-2005 05:24 PM
DataGris Paging not working (event not firing) Ryan Rueckl ASP .Net Datagrid Control 8 06-24-2005 07:13 PM
Control not maintaing viewState and PostBack not firing event. Don ASP .Net Building Controls 1 05-16-2005 01:45 PM
Re: onkeypress not being recognized, or not firing S. Justin Gengo ASP .Net 0 08-26-2003 04:15 PM



Advertisments