I assume you mean the Mono C# compiler (the one that the Mono team develops).
Interestingly, no -- but neither can the native C# compiler (that's what we call the old C# compiler that everyone's using in VS right now)!
Why? The C# compiler is bootstrapped, so we actually compile the compiler with the compiler. It just so happens that a while ago we felt we needed a feature so badly for the C# compiler that we introduced it into the C# language (exception filters) and started using it in the compiler immediately. So in order to compile the compiler, you need a C# compiler that supports exception filters, which right now is just the Roslyn C# compiler. Honestly, the feature (and some other small changes we've made) aren't that complicated, so they could be backported to other compilers, but I don't know why you would want to do that.
A few years ago I was on a small team working on a .NET compiler and runtime -- it compiled MSIL into native code targeting x86 and PowerPC. I remember when working on the part of the compiler that built the exception handling routines running into exception filters and wondering what they were for. We were largely targeting C# as a development environment at the time but ended up implementing them in case anyone wanted to use VB.NET. Funny to see that they're now making their way back into C#, even if it's just in the compiler :)
In certain cases, especially with async, using "throw;" can cause a loss of information in a dump. We want compiler bugs to fail fast -- to immediately crash the compiler for debugging and analysis. By using exception filters we can immediately crash the compiler in erroneous conditions, preserving stack, locals, etc.
This isn't just useful for the compiler, but we felt it was necessary for us to make the most reliable, agile product.
I assume you mean the Mono C# compiler (the one that the Mono team develops).
Interestingly, no -- but neither can the native C# compiler (that's what we call the old C# compiler that everyone's using in VS right now)!
Why? The C# compiler is bootstrapped, so we actually compile the compiler with the compiler. It just so happens that a while ago we felt we needed a feature so badly for the C# compiler that we introduced it into the C# language (exception filters) and started using it in the compiler immediately. So in order to compile the compiler, you need a C# compiler that supports exception filters, which right now is just the Roslyn C# compiler. Honestly, the feature (and some other small changes we've made) aren't that complicated, so they could be backported to other compilers, but I don't know why you would want to do that.
Heh.
A few years ago I was on a small team working on a .NET compiler and runtime -- it compiled MSIL into native code targeting x86 and PowerPC. I remember when working on the part of the compiler that built the exception handling routines running into exception filters and wondering what they were for. We were largely targeting C# as a development environment at the time but ended up implementing them in case anyone wanted to use VB.NET. Funny to see that they're now making their way back into C#, even if it's just in the compiler :)
In certain cases, especially with async, using "throw;" can cause a loss of information in a dump. We want compiler bugs to fail fast -- to immediately crash the compiler for debugging and analysis. By using exception filters we can immediately crash the compiler in erroneous conditions, preserving stack, locals, etc.
This isn't just useful for the compiler, but we felt it was necessary for us to make the most reliable, agile product.
It should. Here's the Roslyn source, and it looks to be all in C# and VB: http://roslyn.codeplex.com/