467,120 Members | 1,246 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,120 developers. It's quick & easy.

Using statements swallowing exceptions

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
no messagebox.


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
Nov 17 '05 #1
  • viewed: 1777
Share:
8 Replies
John B <jb******@yahoo.com> wrote:
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #2
Jon Skeet [C# MVP] wrote:
John B <jb******@yahoo.com> wrote:
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?

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(Appli cation_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
Nov 17 '05 #3
John B <jb******@yahoo.com> wrote:
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(Appli cation_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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #4
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"John B" <jb******@yahoo.com> wrote in message
news:42***********************@news.sunsite.dk...
Jon Skeet [C# MVP] wrote:
John B <jb******@yahoo.com> wrote:
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?

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(Appli cation_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

Nov 17 '05 #5
Jon Skeet [C# MVP] wrote:
John B <jb******@yahoo.com> wrote:
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(App lication_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.

Nope, UI thread. Or rather no threading is involved, so unless
Application.Run runs on a different thread and then instantiates the new
form1 on that thread and then somehow magically switches it, it is the
one (and only) thread.
I havent tried AppDomain.UnhandledException though, so might try that
even though it seems unlikely that it would pick it up as it does not
show up in the JIT debugger as "normal" unhandled exceptions do.

JB
Nov 17 '05 #6
Ignacio Machin ( .NET/ C# MVP ) wrote:
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,

See my reply to Jon. :)
JB
Nov 17 '05 #7
John B <jb******@yahoo.com> wrote:
Nope, UI thread. Or rather no threading is involved, so unless
Application.Run runs on a different thread and then instantiates the new
form1 on that thread and then somehow magically switches it, it is the
one (and only) thread.


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.

(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.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #8
Jon Skeet [C# MVP] wrote:
John B <jb******@yahoo.com> wrote:
Nope, UI thread. Or rather no threading is involved, so unless
Application.Run runs on a different thread and then instantiates the new
form1 on that thread and then somehow magically switches it, it is the
one (and only) thread.

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
Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by gemel | last post: by
12 posts views Thread by bj7lewis | last post: by
40 posts views Thread by Mark P | last post: by
1 post views Thread by Anonieko | last post: by
1 post views Thread by jmalone@optio.com | last post: by
65 posts views Thread by Spiros Bousbouras | last post: by
5 posts views Thread by cronusf@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.