I am calling the following function some where in program that will throw an exception
public static List<Templates> LoadTemplates()
{
// ...
// System.Threading.Thread.CurrentThread.ManagedThreadId == 1 // ID written to log file
System.IO.Directory.GetFiles("does_not_exist_directory");
// ...
}
And I try to catch the exception in the default Program.cs
try
{
// System.Threading.Thread.CurrentThread.ManagedThreadId == 1
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
catch (Exception ex)
{
MessageBox.Show("ERROR CAUGHT");
}
finally { // do clean up }
When run in MSVS, the exception get caught as expected. But when run by double-clicking the .exe in the output directory the exception display in a message dialog stating
EDIT:
To catch the error when running the .exe from output directory, the code must be compiled with handling the Application.ThreadException event
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.Run(new Form());
But then MSVS will behave undesirably by showing the MSVS native “Troubleshooting Tips” borderless message dialog “Unhandled Exception”.
How can I ensure that it behaves the same in and out of MSVS?
Pertaining to the behaviour of exceptions in and out of MSVS, Carsten was right to point me to the code in MSDN but woni helped me realise the situation better.
(It might be otherwise, but) It appears that MSVS hooks its internal event handler to the application when it is run from inside MSVS and that handler is run before my handler in the application. Hence when a unhandled exception occurs, MSVS will show its native “troubleshooting tips” dialog box pointing to the error line.
At this point, if I click continue (F5) to continue execute the code, MSVS will re-throw the exception and this time it will be caught by my own handlers.
Outside of MSVS, no other handlers are subscribed so it just runs my handlers directly.