Visual Studio fans: someone explain debugging to me

[CaleBerkey]

All,

I'm a C# developer and know VS well.  I developed VBA-backed ArcGIS solutions a number of years ago but am now getting back into GIS dev work.  I've stepped through some ESRI examples for creating simple ArcMap Add-Ins and all makes sense, but I'm having problems with my breakpoints and debugging.  Before launching into deeper questions, can someone briefly explain what a healthy ArcMap Add-In debug process looks like?  As a hint for where I'm going:
1) I'm seeing "The breakpoint will not currently be hit. No symbols have been loaded for this document." problems with the breakpoints.
2) The ArcGIS crash reporter gizmo seems to prevent the debugger from halting the code so I can examine the stack trace.  When debugging an ArcMap Add-In and you hit a bug, should Visual Studio then leap into action so I can examine the trace or do I have to examine the dump files?

I'm on VS2010 and ArcGIS 10 on XP. 

Thanks tons,

Cale

[AlexanderGray]

Re-throwing the exception to ArcMap is usually not a good idea unless you know how ArcMap is going to deal with it.  If in the middle of an edit operation and you have an onChange listener and you want to abort the edit, in that case throwing an exception will do that.  Sinking the exception only is usually not good either.  It really depends on the application, the users and the concern for security.  Generally giving the user a warning that something went wrong is a good idea.  Putting the details in a file or in an application event log is good because you, the developer, can look at it after an error has happened in release code.  Some people consider that a security risk because it potentially exposes details of the inner workings (call stack) to the users and will only write to a secure database.