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

Discussion in 'ASP .Net' started by David Lozzi, Apr 23, 2007.

  1. David Lozzi

    David Lozzi Guest

    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
     
    David Lozzi, Apr 23, 2007
    #1
    1. Advertising

  2. 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"
    <> 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
     
    Samuel R. Neff, Apr 24, 2007
    #2
    1. Advertising

  3. David Lozzi

    bruce barker Guest

    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
     
    bruce barker, Apr 24, 2007
    #3
  4. 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 <>
    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)
    >
    >
    >
     
    Samuel R. Neff, Apr 24, 2007
    #4
  5. 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" <> wrote in message
    news:...
    > 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
     
    Alvin Bruney [MVP], Apr 25, 2007
    #5
  6. David Lozzi

    David Lozzi Guest

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



    "Samuel R. Neff" <> wrote in message
    news:...
    >
    > 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 <>
    > 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, May 7, 2007
    #6
  7. David Lozzi

    David Lozzi Guest

    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:...
    > 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" <> wrote in message
    > news:...
    >> 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

    >
    >
     
    David Lozzi, May 7, 2007
    #7
  8. 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" <> wrote in message
    news:...
    >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:...
    >> 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" <> wrote in message
    >> news:...
    >>> 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

    >>
    >>

    >
     
    Alvin Bruney [MVP], May 8, 2007
    #8
  9. David Lozzi

    David Lozzi Guest

    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("ErrorEmailNotifications") =
    True Then
    If Not strError.Contains("viewstate MAC") Then
    Dim msg As New MailMessage

    msg.From = New
    MailAddress(ConfigurationManager.AppSettings("ErrorEmailFrom"))

    Dim toEmails() As String =
    ConfigurationManager.AppSettings("ErrorEmailTo").Split(";")
    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("ErrorEmailFrom"))

    Dim toEmails() As String =
    ConfigurationManager.AppSettings("ErrorEmailTo").Split(";")
    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:...
    > 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" <> wrote in message
    > news:...
    >>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:...
    >>> 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" <> wrote in message
    >>> news:...
    >>>> 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
    >>>
    >>>

    >>

    >
    >
     
    David Lozzi, May 8, 2007
    #9
  10. 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"
    <> wrote:

    >I ran a similar test instead used response.write() and it never reached the
    >finally........
    >
    >
    >
    >"Samuel R. Neff" <> wrote in message
    >news:...
    >>
    >> 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
    >>
     
    Samuel R. Neff, May 8, 2007
    #10
  11. David Lozzi

    David Lozzi Guest

    Interesting.... So the Log.Debug, what does that do?


    "Samuel R. Neff" <> wrote in message
    news:...
    >
    > 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"
    > <> wrote:
    >
    >>I ran a similar test instead used response.write() and it never reached
    >>the
    >>finally........
    >>
    >>
    >>
    >>"Samuel R. Neff" <> wrote in message
    >>news:...
    >>>
    >>> 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
    >>>
     
    David Lozzi, May 10, 2007
    #11
  12. Log.Debug is simply a static wrapper around log4net which I have
    configured to log to a text file.

    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 Thu, 10 May 2007 09:11:27 -0400, "David Lozzi"
    <> wrote:

    >Interesting.... So the Log.Debug, what does that do?
    >
    >
    >"Samuel R. Neff" <> wrote in message
    >news:...
    >>
    >> 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
    >>
    >>
     
    Samuel R. Neff, May 10, 2007
    #12
  13. Finally blocks going off like clock work on my end. I had to convert your vb
    in c# and stub some methods. I simply threw an exception in the constructor
    of the unisession object to duplicate your issue.

    --
    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" <> wrote in message
    news:...
    > 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("ErrorEmailNotifications") =
    > True Then
    > If Not strError.Contains("viewstate MAC") Then
    > Dim msg As New MailMessage
    >
    > msg.From = New
    > MailAddress(ConfigurationManager.AppSettings("ErrorEmailFrom"))
    >
    > Dim toEmails() As String =
    > ConfigurationManager.AppSettings("ErrorEmailTo").Split(";")
    > 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("ErrorEmailFrom"))
    >
    > Dim toEmails() As String =
    > ConfigurationManager.AppSettings("ErrorEmailTo").Split(";")
    > 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:...
    >> 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" <> wrote in message
    >> news:...
    >>>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:...
    >>>> 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" <> wrote in message
    >>>> news:...
    >>>>> 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
    >>>>
    >>>>
    >>>

    >>
    >>

    >
     
    Alvin Bruney [MVP], May 11, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VB Programmer

    Question: Try,Catch,Finally

    VB Programmer, Aug 7, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    369
    Kevin Spencer
    Aug 7, 2003
  2. VB Programmer

    The problem with Try Catch Finally...

    VB Programmer, Aug 12, 2003, in forum: ASP .Net
    Replies:
    23
    Views:
    775
    Chad Myers
    Aug 15, 2003
  3. Ralph Krausse

    ALL 'try/catch/finally' NOT created equal?

    Ralph Krausse, Aug 20, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    423
  4. hansiman

    try catch finally

    hansiman, Jul 14, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    486
    Sean M
    Jul 14, 2005
  5. Alfredo

    Try Catch and Finally

    Alfredo, Aug 11, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    1,381
    Kevin Spencer
    Aug 11, 2005
Loading...

Share This Page