Using statements swallowing exceptions

[John B]

ARGGGGGHH
I have a database class instantiated with a Using statement, then a
reader also instantiated with a using statement.
If the command I use to populate the reader throws an exception, then
that exception gets "swallowed" and never populates back up the callstack.
I added a threadexception handler and this catches the exception at the
top level except before my main form fully loads which does the data
loading in the load event.

Flow of events

MAIN >> Add threadexception handler that shows messagebox with exception
message >> run new form1 >> form1 load >> load data >> exception thrown
After form is loaded and displayed

Combo box selectionchanged >> loads data same as form1 load >> exception
thrown and caught and messagebox displayed.

Any Ideas?

The actual code that invokes the command that throws the exception is

using(DB db = DatabaseManager.CreateDatabase())
{
... setup command
using(IDataReader Reader = db.GetReader(Command)) //db.GetReader throws
exception because of a syntax error
{
}
}

Cheers
JB

 

[Jon Skeet [C# MVP]]

ARGGGGGHH
I have a database class instantiated with a Using statement, then a
reader also instantiated with a using statement.
If the command I use to populate the reader throws an exception, then
that exception gets "swallowed" and never populates back up the callstack.
I added a threadexception handler and this catches the exception at the
top level except before my main form fully loads which does the data
loading in the load event.

That sounds very unlikely. Using statements don't add any exception
handlers, only finally blocks. If you put a statement after your using
block, does that get executed?

 

[John B]

That sounds very unlikely. Using statements don't add any exception
handlers, only finally blocks. If you put a statement after your using
block, does that get executed?

Nope. Not when I force an exception.
the Using bit is a bit misleading I think.
It would just appear that for some reason the exception is getting
swallowed when the form is in the midst of loading.
Why would appear to be the question.
My form loading is this..

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.Run(new Form1());

in the form load...
I load a class from the db which then causes the exception in the db
layer which does not get handled or even seen.

I can force the exception and it gets caught a second time by selecting
a different item in my combo which causes a tree load from the database.

JB

 

[Jon Skeet [C# MVP]]

Nope. Not when I force an exception.
the Using bit is a bit misleading I think.
It would just appear that for some reason the exception is getting
swallowed when the form is in the midst of loading.
Why would appear to be the question.
My form loading is this..

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.Run(new Form1());

in the form load...
I load a class from the db which then causes the exception in the db
layer which does not get handled or even seen.

I can force the exception and it gets caught a second time by selecting
a different item in my combo which causes a tree load from the database.

What thread is this happening in? If it's not in the UI thread, your
ThreadExceptionEventHandler wouldn't see it - you'd need the
AppDomain.UnhandledException instead.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I agree with Jon, this is highly unliked. The only cirscuntance where this
may happen is when the exception occur ni a worker thread. It should be
accesible from the Application.ThreadException or
AppDomian.UnhandledException

Cheers,

 

[John B]

In that case, could you post a short but complete program which
demonstrates the problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

Yeah, will have to try and do one because it is mucho wierdo.

(In passing, it's not really a good idea to do database operations on
the UI thread - it could take a long time to open a connection, or fail
to open it, for instance.)

Agreed.

JB