Losing exceptions

  • Thread starter Thread starter Claire
  • Start date Start date
C

Claire

My call stack has about 6 records in it and most of these points refer back
to runs of code with try/finally and no catch statements.
My program is dropping out at the top of the call stack where it's
attempting to use seek on a memory stream - must be an error here.
The stack is emptying back, finally sections of code are being called and Im
getting no error message.
Should I be getting one? Ive moved from a Delphi background and only
understand how that one works so far - there I'd expect to get errors but
can guarantee that the finally code would run.
(hope you can understand all that)
 
Claire said:
My call stack has about 6 records in it and most of these points refer back
to runs of code with try/finally and no catch statements.
My program is dropping out at the top of the call stack where it's
attempting to use seek on a memory stream - must be an error here.
The stack is emptying back, finally sections of code are being called and Im
getting no error message.
Should I be getting one? Ive moved from a Delphi background and only
understand how that one works so far - there I'd expect to get errors but
can guarantee that the finally code would run.
(hope you can understand all that)
Click to expand...

Not *entirely* sure I understood you - but if you are running on a
thread pool thread, uncaught exceptions won't (by default) do anything
when they've propagated up the call stack.
 
thanks Jon
I do think you understand.
It may be running in a thread. The code has been instigated by a serial port
DataAvailable event from a third party control so it may well be driven by a
secondary thread. Is there any way of viewing process ids in studio?
 
Claire said:
I do think you understand.
It may be running in a thread. The code has been instigated by a serial port
DataAvailable event from a third party control so it may well be driven by a
secondary thread. Is there any way of viewing process ids in studio?
Click to expand...

Well, it will certainly be running in *a* thread. Note that this is
separate from processes - they're not the same as threads.

The easiest way of getting more information would be to add a handler
to the UnhandledException event, which I believe gets called even for
ThreadPool threads.
 
Back
Top