Exception is lost when Finally used in Try statement

[Malcolm]

I'm having problems displaying the full error information for an error
if the error is passed through a function that uses the finally
statement as part of the error handling. The function where it loses
the innerexception error objects is as follows:

Private Sub DoSomething()

Try
conn = New OleDbConnection(GetDatabaseConnectionString)
conn.Open()
...
... some database code which fails
...
Catch ex as Exception
Throw ex
Finally
conn.close
End Try
End Sub

In this example, i want to use the finally statement to make sure the
database connection is closed.
When an error is received in the code above, the catch statement is
processed and at that point, all the error objects are visible through
the innerexception. However, when the error is raised to the function
calling this (and the catch statement), the ex object is not set and i
get the error message: "Object reference not set to an instance of an
object.".

When i remove the Finally section, the parent code correctly has the
details of all internal errors.

Does anyone know how to resolve this?
I have tried declaring a new exception object at the top of the
function to make sure it would stil be in scope in the finally clause,
but this didnt work either.

Thanks

Malcolm

 

[Jay B. Harlow [MVP - Outlook]]

Malcolm,
First: Errors are raised, Exceptions are thrown.

Second I would not catch an exception, just for the sake of Throwing it.

The "Object reference not set to an instance of an object.", sounds like
your connection object itself was not created. I would code the routine
like:

Private Sub DoSomething()
Try
conn = New OleDbConnection(GetDatabaseConnectionString)
conn.Open()
...
... some database code which fails
...
Finally If Not conn Is Nothing Then
conn.close End If
End Try
End Sub

A note on Throw:

Catch ex as Exception

' "Throw Ex" will reset the stack trace to the current routine

Throw ex

Catch ex as Exception

' "Throw" will preserve the stack trace

Throw

From a previous question I answered on Try/Catch

I am using allot the try catch in my code and the question is
if it is good ?

I would favor global exception handlers over a lot of Try/Catch statements,
however I have a number of Try/Finally statements to ensure resources are
disposed of properly. In other words: Try/Finally good, Try/Catch not so
good. See MSDN article below.

it will decrease my performance ?

A Try statement does not decrease performance, the act of throwing &
handling an exception will. In other words if you never throw an exception
there is no performance impact.

is it good to use the exit function in the catch section in case of some
problem (after writing the error in to some log) ?

If I had a problem in a Catch block, I would allow an exception to be raised
that would be handled by a higher catch block or one of my global exception
handlers.

</quote>
Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay

 

[Malcolm]

Why oh why didnt you just start your reply with:

The "Object reference not set to an instance of an object."

Instead, you feel the need to point out such things as 'Errors are
raised, Exceptions are thrown' - what was all that about - are you
looking for a gold star or something??

Anyway, after struggling to gather my interest to want to read the
rest of your post, i appreciate the information and advice. I will
look at the global handler vs. try/catch model to see if it gives me
the same [custom] feedback from wherever the error occurred and the
same control if an error is encountered. I have actually been raising
NEW exceptions which have been inherited so i could add some custom
information, but i'm thinking i may have gone overboard.

As far as a solution to my problem, I found the problem soon after i
posted, the error i was looking at was the unhandled error from the
finally block and was as you pointed out, to do with the conn object
not being set, thus a new exception was created with no information
about the errors that may have occurred prior to the finally block
being called (in this case after the catch block had been called).

Try holding back on the crap next time

Malcolm