text: Yesterday I heard about a cool Whidbey feature that inspired me to come up with this little quiz. The code below when run will print out:
  In try
  In catch
  After try..catch
  class Program
  {
  static void
  {
  try
  {
  Console.WriteLine(“In try”);
  throw new Exception();
  }
  catch (Exception)
  {
  Console.WriteLine(“In catch”);
  }
  Console.WriteLine(“After try..catch”);
  }
  }
  By only adding a few lines of code above the try-statement in the
  In try
  Mystery inserted code
  In catch
  After try..catch
  There are no funky streaming, buffer magic required. Also, you can’t add any code below the try-statement nor can you add any other types, methods, etc to the program. I will give you one hint, you will need the Whidbey pre-release for this one..
  All you have to do is hook the new CatchingException event off the current AppDomain. You can do this without introducing an additional method via anonymous delegates:
  AppDomain.CurrentDomain.CatchingException += delegate( object o, CatchingExceptionEventArgs a )
  { Console.WriteLine( "Mystery inserted code" ); };
  You don’t even need to specify the delegates signature – the compiler can infer it, so the following code will work too:
  AppDomain.CurrentDomain.CatchingException += delegate { Console.WriteLine("Mystery inserted code"); };
  Add Console.WriteLine("Mystery inserted code");
  right after Console.WriteLn("In try");
  Only 1 extra line of code. Yeah I know. Im a dork. 😀
  — Robert
  And what is so cool about this feature? The ability to specify cross-cuts as defined in AOP is not implemented in whidbey. I don’t see much sense in the registering the fact that exception was thrown. Anyway, instead of SEH’s resumable exceptions, CLR doesn’t allow to recover from exceptional situation and continue execution from the faulty instruction (without extensive program logic to handle that situation).
  here is my dodgy version, it compiles in mono not sure about csc
  using System;
  class Program {
  class Exception : System.Exception {
  public Exception() {
  Console.WriteLine("Mystery inserted code");
  }
  }
  static void Main(string[] args) {
  try {
  Console.WriteLine("In try");
  throw new Exception();
  } catch (Exception) {
  Console.WriteLine("In catch");
  }
  Console.WriteLine("After try..catch");
  }
  }
  Damn, I was going to do the same as Ben 🙂
  Of course Steve and Nick are right. But Ben’s answer is very cool too! 🙂
  What Ben wrote was the first thing that came to my mind and was an obvious way to get the desired output, but I think Nick and Steve, who both gave answers I didn’t think of, probably have the solution Brad is looking for.
  Andrei: I can think of several uses for such a feature. For example, it makes a debugger’s implementation of BreakOnException much easier to implement (I’m toying with writing one for some .Net-based scripting support I added to an app of mine). Also, it can greatly help in those issues like XML deserialization or called to ConfigurationSettings.GetConfig, where exceptions can get thrown very deep in the code and are either masked by returning null (ugh) or wrapped in several layers of exceptions, like ConfigurationSettings is so fond of doing
  Of course, the downside to this is that you can get burned when folks use exceptions for non-exceptional cases. IBM’s Java Sax parser made it damn-near impossible for me to effectively use BreakOnException in VAJ, because it threw exceptions EVERYWHERE.
  It also might be useful if you just want to do something silly like Debug.WriteLine the full text of every exception thrown; without modifying all your catch blocks to save the full gory details. Or maybe you don’t even own the actual catch block, and don’t want to rethrow exceptions everywhere. But then, I have not RTFM.
  System.out.println("In trynMystery inserted codenIn catchnAfter try..catchn");
  System.exit(0);