Why doesn't C# have support for first pass exception filtering?

Answer 1

In regards to the first question, if there was a public statement, then it was more than likely put on the web somewhere, in which case, Google should turn up something (if it exists).

If it is a direct email with the C# team, then it is more than likely that it is under NDA, so it wouldn't be able to be published anyways.

With the second question, there is a search capability on Microsoft Connect which they prompt you to use before entering a new suggestion. If you can't find it, then there probably isn't one.

My recommendation would be to put a suggestion in, and then promote it to get others to weigh in on it.

Answer 2

As I understand them, at the moment of rethrow, the finally handlers in the inner functions are executed and that's what creates problems for you.

But let's say you have an exception filter that passes the exception through without actually rethrowing it. You'll still have to handle it somehow somewhere, and you will run in the same kinds of problems (finally effects) there.

So unless I am misunderstanding something, there is not great gain from having language-supported exception filters.

Answer 3

Using Exception Filter Inject may be simpler than using the delegate workaround.

For a real answer to your question you will need a response from Anders Hejlsberg, or someone who was in the original design meetings. You might try seeing if you can get it asked by the Channel 9 interviewer next time the C# design team is interviewed.

I'd guess that when the original decision was made, exception filters were seen as an unnecessary complication that might do more harm than good. You can certainly see a desire to remain 'silent' about unproven features in this interview about the decision not to support checked exceptions: The Trouble with Checked Exceptions .

I think the postmoterm diagnostic scenarios argue strongly for providing access to exception filters in the language. However those scenarios may not have been articulated at the time. Also those scenarios really need proper tooling support, which certainly wasn't available in V1. Finally there may be big negatives about adding this feature that we are not considering.

If there isn't a connect bug on this you should enter one and encourage others to vote it up. [I'd recommend asking for access to the CLR feature rather than attempting to design how it fits in the language.]

Answer 4

I don't believe that Java has a filter option either. Guessing that if it did, we would also see one in C#. VB.net likely has one by chance given that the VB team started with a clean slate.

One thing that might work in your favor as far as gaining this option in a future version of C# is Microsoft's stated goal to maintain parity between laguage features in future versions of C# and VB.net. I would put forward my arguement based on that.

http://www.chriseargle.com/post/2009/01/Parity-Between-Languages.aspx

Answer 5

As to any existing connect bugs. The following issue deals with exception fliters. The user did not explicitly state they wanted them be an actual filter in the sense of when they execute but IMHO it's implied by the logic.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=401668

Besides that issue though, there are no issues I can find or know of that are related to what you are looking for. I think it would do good to have a separate issue which explicitly calls out the want for VB.Net style exception filters.

I wouldn't worry too much about introducing a duplicate question if you've done a bit of due diligence looking for an existing one. If there is a dupe, Mads will dupe it accordingly and link you to the main request.

As for the part of getting an official response from the C# team, you will likely get that when you either 1) file a connect bug or 2) get duped against the main bug. I really doubt there is an official reason / justification out there right now.

Here's my speculation on the issue: My guess is that this feature simply wasn't on the original C# 1.0 feature set and since that time there hasn't been enough demand to make it into the language. The C# and VB team spend an unbelievable amount of time ranking language features at the start of every ship cycle. We have to make some very difficult cuts at times. Without sufficient demand there is very little chance a feature will make it into the language.

Up until recently I bet you would be hard pressed to find 1 out of 10 people who understood the difference between VB.Net's Try/When and just using a plain old if statement in a C# catch block. It seems to be a bit more on peoples minds lately so maybe it will make it into a future version of the langauge.