Simon,
I don't have an answer for your question, but I want you to consider that
there is one special group of exception - OutOfMemoryException,
StackOverflowException and ExceutionEnglineException that should be treated
in a special way. What makes them unique is that they are not thrown by
framework's or users code, but rather from the CLR itself when something
goes wrong and the state of the runtime engine is not stable.
Depending on the circumstances when one of these is thrown, it might be even
not possible to catch it. Even more it is most likely that when such
exception is thrown the *finally* blocks in the code (if any) are not going
to execute. This is because, for example in a case of stack overflow, in
order to prepare and throw the exception as well as for the code to catch
and recover from it more stack space could be required. CLR may find
possible to discover stack overflow situations before it runs out of stack
memory and in this case it will throw an exception that can be caught. If
the guard page for the stack gets overridden. that's it, the CLR throws an
exception and terminates the application and no handlers are executed.
Because of this even if the code caches such exception the code should never
try to recover from it. It should log the exception and terminate the
application.
The only sure thing that can be used to catch stack overflow is to install
Windows SEH handler. Since v2.0 .NET framework provides a class that can be
used to install such cases - RuntimeHelpers.
For more info I'd suggest reading the following article.
http://msdn.microsoft.com/msdnmag/is...0/Reliability/
Why you can handle the exception in your machine, but on the client machine
it shows up as unhandled I guess it is because of different runtime
environments. For example you may have more memory installed that the user.
It is just a wild guess though.
HTH
Stoitcho Goutsev (100) [C# MVP]
"Simon Tamman {Uchiha Jax}"
<i_**********************************@NOSPAMhotmai l.com> wrote in message
news:oe****************@newsfe7-gui.ntli.net...
Now this is bugging me.
I just released software for a client and they have reported an unhandled
stack overflow exception.
My first concern is that the entirity of the UI and any threaded
operations
are all within Try Catches to help me locate the problem and the
origination
of any problem by specifiying an error code in the "Catch" section.
So theoretically this shouldn't have been possible (at which point we all
say "yeah, right...."(in a sarcastic manner)). However.......
I get the data files from the client and try to run those files in my
install (from an .msi) of the application. I get the same unhandled
exception.
However when I then run the program within Visual Studio (which has not
been
changed since the .msi was produced) I don't get an unhandled error. I get
my error code instead!
The call originates in a seperate thread, this thread fires an event which
a
form has subscribed to. The form eventhandler calls the data object which
is
stored within a .dll and initiates the process that causes the exception.
The method in the seperate thread where the event is fired is Try Catched,
the method in the form that utilises the data object is Try Catched. The
method within the data object itself is NOT Try-Catched.
Is it the case that VS studio is hiding the true results of such an
exception? If a thread executes a method in a .dll and the .dll method
calls
throws an exception will that not be caught by a Try Catch in the
originating method?
Please advise, as this confuses the hell out of me.