Quiz: More Exception Mysteries

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 Main(string[] args)

    {

        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 Main() method have it printed out:

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..    

 

Published 21 October 04 07:59 by BradA
Filed under:

Comments

# Steve Maine said on October 21, 2004 9:04 PM:
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" ); };

# Nick Wienholt said on October 21, 2004 9:26 PM:
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"); };
# Robert Kozak said on October 21, 2004 10:24 PM:
Add Console.WriteLine("Mystery inserted code");
right after Console.WriteLn("In try");

Only 1 extra line of code. Yeah I know. Im a dork. :-D

-- Robert
# Andrei said on October 21, 2004 11:29 PM:
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).
# Di .NET e di altre amenita' said on October 22, 2004 3:10 AM:
# Ben Murphy said on October 22, 2004 12:53 AM:
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");
}
}
# Ernst Kuschke said on October 22, 2004 3:58 AM:
Damn, I was going to do the same as Ben :)
# mihailik said on October 22, 2004 4:00 AM:
Of course Steve and Nick are right. But Ben's answer is very cool too! :-)
# Raymond Lewallen said on October 22, 2004 4:41 AM:
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.
# Keith Patrick said on October 22, 2004 7:53 AM:
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.
# RJ said on October 22, 2004 9:12 AM:
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.
# cheater said on October 22, 2004 1:36 PM:
System.out.println("In try\nMystery inserted code\nIn catch\nAfter try..catch\n");
System.exit(0);
New Comments to this post are disabled

Search

Go

This Blog

Syndication

Page view tracker