inline
"Ryan Seghers" <no*****@nowhere.com> wrote in message
news:cN*****************@news.uswest.net...
If your handler getting called for other exceptions? I have no idea how
stable the clr is when an OutOfMemoryException occurs - you may be very
constrained on what you can do. At the very least I would pre-allocate
any objects you need to log the exception.
Yes, my handler gets called for other exceptions. I explicitly threw an
ApplicationException to test that.
As far as stability after an OutOfMemoryException I agree. However, I
suppose statistically speaking that on average when an allocation fails
there will still be half the amount of memory I requested left. Sure
would be nice if the CLR reserved an additional small block of memory for the
out-of-memory case. Then it could free that block and then let my
exception handler run.
It preallocates an exception object for those types so they can ensure that
an exception of those types are always available for use. I would not
therefore assume that the runtime will call your catch handler - it may nust
use that type for logging and diagnostic purposes.
I would expect that so long as your handler is subscribing to the
unhandled exception from the context of the default appdomain you should be able
to get all exceptions (except probably the ExecutionEngineException, which
is completely fatal, possibly a StackOverflowException).
Apparently not. Evidently OutOfMemoryException is considered as fatal as
the other two you mentioned. When I explicitly throw an
OutOfMemoryException it doesn't get to the exception handler. When I
throw an ApplicationException in the same place and under the same circumstances
it does get to the handler.
There must be code in the clr's exception handler looking for specific
exception types and giving them special handling (i.e. initiating an
abnormal termination) when encountered. There's supposed to be a single SEH
frame in the CLR around the entire .net application that all exceptions get
funneled through and it is likely there where the code forces the
application to terminate.
This means that there are some types that you cannot throw. At the very
least MSDN should document this because there are some exceptions defined in
modules in the CLR that are there for applications to use (e.g.
ArgumentException) and obviously there are others that are not. For these
types I am surprised that MSFT allowed user applications to even create
exceptions of this type; they could have made the constructor private so
that you could not new one of these and then provide an internal factory
method for their own use.
MSFT should document which exceptions are handled like this so that
application writers would know which exceptions they should never throw. It
would be even better if applications could not even create those exceptions.
I currently know of 3 like this; OutOfmemory, StackOverlow, ExecutionEngine.
I would like to know if there are others.
I would treat those 3 exceptions as fatal and just rethrow them if I ever
catch one (not likely), but never throw one myself.