Handling critical exceptions in different appdomains - c#

Let's asume the folowing bit of code, which allows you to call a class in a different AppDomain and handle almost any exception:
using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
namespace MyAppDomain
{
class Program
{
static void Main(string[] args)
{
AppDomain myDomain = null;
try
{
myDomain = AppDomain.CreateDomain("Remote Domain");
myDomain.UnhandledException += new UnhandledExceptionEventHandler(myDomain_UnhandledException);
Worker remoteWorker = (Worker)myDomain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(Worker).FullName);
remoteWorker.VeryBadMethod();
}
catch(Exception ex)
{
myDomain_UnhandledException(myDomain, new UnhandledExceptionEventArgs(ex, false));
}
finally
{
if (myDomain != null)
AppDomain.Unload(myDomain);
}
Console.ReadLine();
}
static void myDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
Exception ex = e.ExceptionObject as Exception;
if (ex != null)
Console.WriteLine(ex.Message);
else
Console.WriteLine("A unknown exception was thrown");
}
}
public class Worker : MarshalByRefObject
{
public Worker()
{
}
public string DomainName
{
get
{
return AppDomain.CurrentDomain.FriendlyName;
}
}
public void VeryBadMethod()
{
// Autch!
throw new InvalidOperationException();
}
}
}
Now the problem is, allmost any exception can be handled, not every exception. A StackOverflowException for example will still crash the process. Is there a way to detect critical exceptions in different appdomains and handle these by unloading the AppDomain, but still allow other AppDomains to continue?

Unfortunately a StackOverflowException cannot be caught.
See: http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx
...
Starting with the .NET Framework
version 2.0, a StackOverflowException
object cannot be caught by a try-catch
block and the corresponding process is
terminated by default.
...
Update:
After further investigation in my old issues I found this old thread:
http://www.c-sharpcorner.com/Forums/ShowMessages.aspx?ThreadID=36073

Since .net framework 2.0, a StackOverflowException cannot be catched using a try-catch statement.
http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx

Related

A global error handler for a class library in C#

Is there a way to catch and handle an exception for all exceptions thrown within any of the methods of a class library?
I can use a try catch construct within each method as in sample code below, but I was looking for a global error handler for a class library. The library could be used by ASP.Net or Winforms apps or another class library.
The benefit would be easier development, and no need to repeatedly do the same thing within each method.
public void RegisterEmployee(int employeeId)
{
try
{
....
}
catch(Exception ex)
{
ABC.Logger.Log(ex);
throw;
}
}
You can subscribe to global event handler like AppDomain.UnhandledException and check the method that throws exception:
AppDomain.CurrentDomain.UnhandledException += CurrentDomainOnUnhandledException;
private static void CurrentDomainOnUnhandledException(object sender, UnhandledExceptionEventArgs unhandledExceptionEventArgs)
{
var exceptionObject = unhandledExceptionEventArgs.ExceptionObject as Exception;
if (exceptionObject == null) return;
var assembly = exceptionObject.TargetSite.DeclaringType.Assembly;
if (assembly == //your code)
{
//Do something
}
}

how can I prevent swallowed exceptions in 3rd party libraries from triggering the VS debugger?

using System;
using System.Diagnostics;
using NUnit.Framework;
namespace TestExperiment
{
[TestFixture]
internal class TestAAA
{
[Test]
public void Test_ThrowSwallowThirdParty()
{
ThrowSwallowThirdParty();
}
[Test]
public void Test_ThrowSwallowLocal()
{
ThrowSwallowLocal();
}
[DebuggerStepThrough]
[DebuggerNonUserCode]
[DebuggerHidden]
public void ThrowSwallowThirdParty()
{
ThirdPartyLibrary.ThrowEmbedded();
}
[DebuggerStepThrough]
[DebuggerNonUserCode]
[DebuggerHidden]
public void ThrowSwallowLocal()
{
try
{
throw new Exception();
}
catch (Exception e)
{
}
}
}
// imagine this is a 3rd party library provided in a dll which I am referencing
internal static class ThirdPartyLibrary
{
public static void ThrowEmbedded()
{
try
{
throw new Exception();
}
catch (Exception e)
{
}
}
}
}
As per here and here I understand you can use the [DebuggerHidden] attribute to prevent the debugger from stopping at a swallowed exception even if it is told to break on all thrown exceptions. This works for Test_ThrowSwallowLocal(). However I would like to duplicate this when calling code in a 3rd party library which is throwing and swallowing its own exceptions - which I am trying to emulate in Test_ThrowSwalloThirdParty() - at the moment the debugger continues to break at the exception throw.
Is there a way to avoid this without editing the ThirdPartyLibrary code (which I cannot easily do?)
I would look into the Just My Code Option in VS

Why exception in child domain close program?

Why exception in one application domain affect another application domain?
How do I prevent the closing of the program?
using System;
using System.Reflection;
using System.Threading;
namespace domain
{
public class Worker : MarshalByRefObject
{
public static void NotMyCodeThreadProc()
{
throw new Exception();
}
public void NotMyCode()
{
var thread = new Thread(NotMyCodeThreadProc);
thread.Start();
thread.Join();
}
}
class Program
{
static void Main()
{
AppDomain ad = AppDomain.CreateDomain("New domain");
Worker remoteWorker = (Worker) ad.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, "domain.Worker");
try
{
remoteWorker.NotMyCode();
}
catch
{
}
Console.WriteLine("!");
Console.ReadLine();
}
}
}
In .NET 2.0 (and above), an unhandled exception in a thread causes the entire process to terminate.
You can change that policy by following Hans' advice, or you can simply wrap your code with try/catch and handle the exception.

ServiceBase.Run, why can't I catch it's exceptions, or react to them in some other way?

I'm calling the following from my entry point static main method:
try { ServiceBase.Run(new MonitorSer()); }
catch (Exception ex) { Console.WriteLine(ex.Message + Process.GetCurrentProcess().MainModule.FileName); }
MonitorSer is an instance of:
class MonitorSer : ServiceBase {
and the entry main method is a member of my class:
[RunInstaller(true)]
public class WindowsServiceInstaller : Installer {
I've had good results catching exceptions for debugging but sometimes they seem to find their own way around my traps, as in this case.
I get a windows box flash up telling me I need to install using installutil when what I really want is to find the name of this process and call it again with the -i switch which I have wired up to make it install intself (credit to those here who contributed/recycled that code).
What makes this more frustrating is that if I set breakpoints upto (or on) the call to ServiceBase.Run, it will fail silently and I am left with the blinking console.
UPDATE
static void Install(bool undo, string[] args)
{
try
{
Console.WriteLine(undo ? "uninstalling" : "installing");
using (AssemblyInstaller inst = new AssemblyInstaller(typeof(MonitorSer).Assembly, args))
{
IDictionary state = new Hashtable();
inst.UseNewContext = true;
try
{
if (undo) inst.Uninstall(state);
else
{
inst.Install(state);
inst.Commit(state);
}
}
catch
{
try
{
inst.Rollback(state);
}
catch { }
throw;
}
}
}
catch (Exception ex)
{
Console.Error.WriteLine(ex.Message);
}
}
I clumped the entry point here so I could call the above function, I'll try moving that to another class and setting the entry point there, but I know I can make this entry point (that you, Dmitry, deny) work by calling itself with the appropriate argument to install- which only the BaseService class can do- correct me if I am wrong.
[RunInstaller(true)]
public class WindowsServiceInstaller : Installer
Is not your entry point. This will get called once when you install your service using InstallUtil.exe. Entry point can be specified in the project properties and it usually defaults to Program.Main. You should not be starting your service from Installer class.
CLR will let you know of unhandled exceptions if you subscribe to this event:
static void Main() {
...
AppDomain.CurrentDomain.UnhandledException
+= CurrentDomain_UnhandledException;
...
}
private static void CurrentDomain_UnhandledException(
Object sender,
UnhandledExceptionEventArgs e) {
if (e != null && e.ExceptionObject != null) {
// log exception:
}
}
This event provides notification of uncaught exceptions. It allows the
application to log information about the exception before the system
default handler reports the exception to the user and terminates the application
...
Starting with the .NET Framework version 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.
application.
Another place where you might want to log exceptions in windows service (because .NET/SCM will swallow startup exceptions):
protected override void OnStart(String[] args) {
try {
} catch(Exception e) {
// log exception:
throw;
}
}

How to Automatically re-raise Exceptions

If you wrap a call to HttpResponse.End within a try catch block, the ThreadAbortException would automatically be re-raised. I assume this is the case even if you wrap the try catch block in a try catch block.
How can I accomplish the same thing? I do not have a real-world application for this.
namespace Program
{
class ReJoice
{
public void End() //This does not automatically re-raise the exception if caught.
{
throw new Exception();
}
}
class Program
{
static void Main(string[] args)
{
try
{
ReJoice x = new ReJoice();
x.End();
}
catch (Exception e) {}
}
}
}
You can't change ordinary exceptions to have this behaviour. ThreadAbortException has special support for this that you can't implement yourself in C#.
ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block.
It's as simple as using the plain throw statement.
throw;
in the relevant catch block. Note that this is advantageous over doing throw e; because it preserves the call stack at the point of the exception.
Of course, this isn't automated in perhaps the sense you want, but unfortunately that is not possible. This is pretty much the best solution you'll get, and pretty simple still I think. ThreadAbortException is special in the CLR because it is almost inherent in thread management.
In the case of your program, you'd have something like:
namespace Program
{
class ReJoice
{
public void End()
{
throw new Exception();
}
}
class Program
{
static void Main(string[] args)
{
try
{
ReJoice x = new ReJoice();
x.End();
}
catch (Exception e)
{
throw;
}
}
}
}
You mean like this?
namespace Program
{
class ReJoice
{
public void End() //This does not automatically re-raise the exception if caught.
{
throw new Exception();
}
}
class Program
{
static void Main(string[] args)
{
try
{
ReJoice x = new ReJoice();
x.End();
}
catch (Exception e) {
throw e;
}
}
}
}
Edit: It doesn't re-raise the exception because the meaning of "catch" is to handle the exception. It is up to you as the caller of x.End() what you want to do when an exception occurs. By catching the exception and doing nothing you are saying that you want to ignore the exception. Within the catch block you can display a message box, or log the error, kill the application entirely, or rethrow the error with additional information by wrapping the exception:
throw new Exception("New message", e);

Categories

Resources