问题
As far as i know, when a first chance exception occurs, the debugger is notified(if any) and then if still unhandled, the system searches for the nearest frame based exception handler in the stack if any.
I was reading this link when I came to know about vectored exception handling.
Question1) I was wondering if there is any way we can do that in managed code?
Question2) I think that any try{}catch{} is a frame based handler but what happens when we register a handle at certain events like
AppDomain.CurrentDomain.UnhandledException += (x, y) =>
{
Console.WriteLine("Unhandled exception");
};
what are these?
回答1:
The debugger is only notified of an exception if it is attached. For example, if you are debugging in Visal Studio, then it would be called first, and if it passed on the exception, the exception handlers would be called. To have the debugger stop on all exceptions, from Visual Studio select the Debug menu and select Exceptions and then choose the exceptions you want the debugger to halt at. If none of those handlers (or there are no handlers) then the debugger would be called a 2nd time to stop execution and display a general message that an exception had occurred. If on the other hand, the debugger is not attached, then the debugger won't be notified - which is the case for 99%+ of all managed production code.
Vectored exception handling is a low level api intended to be used from unmanaged code - i.e. C++. Your very first choice from managed code (C#) should be to use structured exception handling with try/catch/finally blocks. Most (99%+) managed code developers using a language like C#, including myself, have found structured exception handling to be quite adequate.
If you still think you need to use this api, you will have to call AddVectoredExceptionHandler by using P/Invoke, which is one way unmanaged code can be called from managed code. There are a couple of caveats. See this link for a general overview. Mike Stall's blog suggests avoiding vectored exceptions in managed code. In this thread, Mike Stall says that unmanaged vector exception handlers should never call back into managed code. He also suggests that managed exceptions are an undocumented feature in vectored exception handling and that MS could eliminate that support in a future release of the CLR, so use at your own peril.
The AppDomain.UnhandledException event is only called when no other handler is found. It could be used in situations where it is desired to log some information about an unhandled exception, but there is little time to put in proper structured exception handling to a large base of existing code, or perhaps you don't have access to the code that is throwing the exception. Otherwise, try/catch/finally blocks should be used instead.
You might also try taking a look at the AppDomain.FirstChanceException event, which occurs before the first exception handler is called. This one might be useful if all you want to do is log some information for certain exceptions thrown in someone else's code that you don't have access to that are handled. It is only a notification though, and not an exception handler. I have never used it before, so don't know how much it might affect performance. My concern here is that Microsoft developers sometimes throw exceptions in the CLR for various things other than true errors. To see this in action, try setting the debugger to break on every exception, including the CLR Runtime exceptions. This can be done in Visual Studio from the Debug menu and choosing Exceptions. So, I don't know how much of an impact it would have on performance since all the CLR exceptions will probably raise this event as well. To be fair, the last time I did this was with VS 2008. This might not be true or as true with later versions of the CLR. I don't see a way to limit the exceptions this event will fire either. So, you would need to filter out the exceptions you are not interested in and experiment to guage its impact on performance.
来源：https://stackoverflow.com/questions/18660807/is-it-possible-to-do-vectored-strctured-exception-handling-in-c