I have written a command manager that uses reflection to make calls to various methods and it works wonderfully except that when an exception happens in one of the handlers the break into debugging happens in the command manager and not at the point the exception was originally thrown. Is there a way to get it to break into the exception immediately rather than at the point I call Invoke?
views:
42answers:
2
+1
A:
Do you mean while debugging? If yes, then go to Debug menu -> Exceptions, then you can configure the debugger to break when an exception is thrown instead of when it is caught.
You can either enable that feature for all exceptions, or if you know the type of the exception that you're interested in, then you can enable it for only that exception.
M4N
2009-11-05 19:38:19
Because the command manager can execute any command, the type of the exception is unknown. Wouldn't this adversely affect other types of exception catching. I just want the calls through Invoke to break where it's called. Otherwise I'll be catching all sorts of exceptions that will eventually be handled won't I?
Orion Adrian
2009-11-05 20:13:01
+1
A:
Open the Exceptions settings window by choosing Debug->Exceptions.
In there, you can find the CLR exception that is being thrown. You can change the setting to break when the exception is Thrown instead of User-unhandled.
That will make it break at the appropriate time.
Reed Copsey
2009-11-05 19:39:10
Because the command manager can execute any command, the type of the exception is unknown.
Orion Adrian
2009-11-05 20:11:42
Unfortunately, this is just the way the debugger in .NET works. You can't have it break on thrown exceptions if they're in a background thread, etc... It'd be nice, but it's really just one or the other. THat being said, I don't bother with this -the inner exception information has the correct stack trace and proper line numbers, so it's annoying, but not really needed to debug the problem.
Reed Copsey
2009-11-05 20:18:52
That's how I've been getting around it, but it also means that I don't get the proper stack for the call which means I have to hope the exception is consistent enough that it'll happen next time after I put a breakpoint on the throwing code. Regarding your comment about another thread, I'm fairly certain it's all happening in a single thread.
Orion Adrian
2009-11-05 20:41:07