Develop Reference

C# .NET VSTO Excel Add-In Global Error Handler Options

I have an Excel Add-In created using VSTO and C# .NET. I am interested in creating a handler for unhandled exceptions. Based on some research and other posts, there are a couple of events that I can register for and they seem to do the trick.
So, something like this:
private void ThisAddIn_Startup(object sender, EventArgs e)
{
AppDomain.CurrentDomain.UnhandledException += this.CurrentDomain_UnhandledException;
}
private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
var errorDialog = new ErrorDialog("Something went wrong", e.ExceptionObject as Exception);
errorDialog.ShowDialog();
}
Great. HOWEVER, as soon as the error dialog shows and exits, i.e. the code above returns/completes, the code that triggered the exception resumes exactly where it left off, thus re-triggering the exception. It becomes an infinite loop.
In WPF, we would simply mark it as handled, (e.Handled = true;) and that would take care of it. However I don't see a similar option here in WinForms.
What are my options with Excel Add-Ins VSTO/Win Form exception handlers?
The only thing I can think of is to catch the first event and ask the user to restart the app.
There has to be something better. How can I really handle the exception?

How do I record stacktrace of StackOverflowException?

I've read answers to similar questions about handling StackOverflowException, and I understand that starting from .net 2.0, the StackOverflowException terminates the process, and I'm fine with this.
However, when stack overflow happens, I want to know why it happened, specifically I want to record the stacktrace.
In Microsoft documentation, it's stated that you can process stackoverflow exception if you set proper attributes to the method:
Starting with the .NET Framework 4, this event is not raised for
exceptions that corrupt the state of the process, such as stack
overflows or access violations, unless the event handler is
security-critical and has the
HandleProcessCorruptedStateExceptionsAttribute attribute.
So I've tried setting HandleProcessCorruptedStateExceptionsAttribute to my handler method:
class Program
{
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
Main(null);
}
[SecurityCritical]
[HandleProcessCorruptedStateExceptionsAttribute]
private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine(e.ExceptionObject);
}
}
The program still terminates without giving me the stacktrace.
How can I record a stacktrace for StackOverflowException?

Handle unhandled exception from c++ dll in WPF

My WPF app uses external DLL's method (c++, nothing with UI, just logic) like this:
[DllImport("myExternDll.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
private static extern int externalMethod(string str);
int SomeWPFMethod()
{
int res;
try
{
res = externalMethod(str);
}
catch(Exception e)
{
LogError(e)
return -1;
}
return res;
}
Note, that SomeWPFMethod called in separate from UI thread (if this matter).
When there is something wrong inside dll I've got
An unhandled exception of type 'System.AccessViolationException'
occurred
exception.
A have unhanded exception method set for app, but this does nothing:
Application.Current.DispatcherUnhandledException += Current_DispatcherUnhandledException;
private void Current_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
if (System.Diagnostics.Debugger.IsAttached)
{
e.Handled = false;
return;
}
ShowUnhandledException(e);
}
Is there possible somehow to handle the exception to prevent application from crash?
If extern method fails, I don't want to do anything, but app should still work. Now it's crashed.

Since SomeWPFMethod is called in a thread separate from the UI thread,
Application.Current.DispatcherUnhandledException
will not be able to catch this exception since it catches unhandled exceptions only from the main UI thread created by WPF.
Seems you need to use
AppDomain.CurrentDomain.UnhandledException
It catches unhandled exceptions generated from all threads running under the context of a specific application domain.
You can refer to the following articles that cover proper way to handle unhandled exceptions in WPF at great depth -
https://dzone.com/articles/order-chaos-handling-unhandled
https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx
Hope this solves your problem.

Global exception handler with UnhandledExceptionEventArgs not working

After reading this MSDN page, I've created a global exception handler in my .net class library, for logging purposes, which looks like this:
static void OnException(object sender, UnhandledExceptionEventArgs args)
{
Exception ex = (Exception)args.ExceptionObject;
Logging.LogException(ex);
}
But then if I throw new UnauthorizedAccessException() or throw new Exception() from a method, this does not catch it at all.
The MSDN page says:
UnhandledExceptionEventArgs provides access to the exception object
and a flag indicating whether the common language runtime is
terminating. The UnhandledExceptionEventArgs is one of the parameters
passed into UnhandledExceptionEventHandler for the
AppDomain.UnhandledException event
I believe what I'm doing falls under the AppDomain (and not ThreadException)? What am I doing wrong here?
PS. I'm trying to avoid a try-catch block, since apparently it's bad practice. This class library is called from a windows service which runs periodically so I'd rather not let it 'crash' to avoid memory leaks due to unforeseen exceptions and would prefer to monitor the event logs regularly.

You will need to install the exception handler in the current app domain in order for it to fire:
AppDomain.CurrentDomain.UnhandledException += OnException;
Otherwise its just a method declaration that will never be called.

You mention that you are trying to avoid a try catch, but inside your handler, that wouldn't be a bad idea:
static void OnException(object sender, UnhandledExceptionEventArgs args)
{
try
{
Exception ex = (Exception)args.ExceptionObject;
Logging.LogException(ex);
}
catch
{
// do nothing to silently swallow error, or try something else...
}
}
...Because you don't want to explode in your error handler. Either swallow if stability is of primary importance, or try a secondary (more basic) logging method to insure that no exception falls through the cracks.
Normally, swallowing an exception silently is a poor practice, but this is inside an error handling block where failure means crashing an app.

Is there a centralised error handling process in C#

Is there a way to centralize the error handling or exceptions handling without using try catch methods?

Use AppDomain's UnhandledException event:
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
// log the exception
}
For ASP.NET use you will use glabal.asax.

If this is for ASP.NET you can add a Global.asax file to the website and handle the Application_Error method.
This is how I generally use it:
void Application_Error(object sender, EventArgs e)
{
// Code that runs when an unhandled error occurs
if (!System.Diagnostics.EventLog.SourceExists("MySource"))
{
System.Diagnostics.EventLog.CreateEventSource("MySource",
"Application");
}
System.Diagnostics.EventLog.WriteEntry("MySource",
Server.GetLastError().ToString());
}

You could try AOP based addons like PostSharp that injects your exception handling code to your classes and/or methods that have custom attributes. This is done post-compile, so your source code remains clean. Check this out - http://www.sharpcrafters.com/postsharp/documentation/getting-started

If you are using WinForms, you could have a look at my other answer related to this. It does use try-catch though, as there is no other way that I know off.
See other answers for ASP.NET and possible other .NET uses.