Comment by Pxtl | Hacker News Reader

Comment by Pxtl | Hacker News Reader

I looked at this earlier - on the one hand, I like that they're directly tackling known pain-points in the language. The declaration expression "out var x" thing is, imho, great. The TryParse syntax has always been a problem because you have to declare the variable the line before, which means no type inferencing and whatnot. Also, good for casting as they show.

Using static is great - finally we've liberated the verbs in the kingdom of nouns.

However, some of them have really ugly syntax. I know they wanted to get rid of the boilerplate problem of declaring and setting into a read-only member, but the primary constructor syntax is monstrous - declaring local variables inside of your constructor? Really? I feel like just having a "readonly set" access modifier on properties (both auto and explicit) would have been sufficient.

The new dictionary accessor seems silly.

Exception filters seem just as pontless in C# as they did in VB (nesting an "if/else throw" into a catch clause wasn't too hard).

The crazy null ?. operator I'm unsure about... that one I'll have to use. I've run into the problem enough times to see why they did it, though.

Exception filters aren't pointless. They preserve the stacktrace, meaning the debugger will break at the original throw and not the throw; in your catch (I'm on mobile so I don't have a code sample, sorry, I hope you get what I mean)

Throw in a catch block with no exception argument preserves stack-trace.

That is

catch(Exception ex) {throw;}

Rethrows without meddling with ex.

Throw in a catch block with no exception argument preserves stack-trace.

No it doesn't. If you then let that exception fall out as unhandled, the stack trace will be centered on the second throw, not on the original.

This case is confusing and a lot of people miss the subtle difference.

In one case you

try { Throws(); } catch(Exception ex) { DoHandling(); throw ex; } // BAD!

This one does lose the initial site of the first exception, and throws it as a new exception at this location, centering the stack trace on this line.

This is what you want to do:

try { Throws(); } catch { DoHandling(); throw; }

Notice you do not name, or capture the exception. This causes your handling to execute, but crucially it re-throws the original exception untouched, with the original stack trace, centering on the original exception thrown location.

So you can easily lose that information if you re-throw naively. Good code tools should yell at you for doing this most of the time. Note in some cases you want to add information, so you can throw a new exception with new information, but set the InnerException property to the original causing exception.

See http://msdn.microsoft.com/en-us/library/system.exception.inn...

I thought that was called try...finally

No, finally is always executed. The catch handler only executes when there's an exception.

Yes, as noted, it's a three part structure:

try { MayThrowException(); } catch(MyExceptionType ex) { HandleIfException(ex); } finally { AlwaysRunCleanupRegardless(); }

This case is confusing and both you and the documentation are wrong. :)

You're confusing the Exception.StackTrace with the actual CLR stack trace. The minute you catch an exception in the CLR the accurate trace is destroyed. This is pathological for crash dumps, where it's imperative that you have an accurate trace for debugging.

If you don't believe me, go into VS and do the following.

1. Throw an exception.

2. Make sure that exception is not listed in exceptions to break on.

3. Catch and rethrow that exception using "throw;".

4. Let that exception filter out of the program unhandled.

5. Run in debugger.

Notice where your stack trace is centered on -- the "throw;" call.

... then fix the "throw;" call, don't bolt on a language feature to work around the fact that "throw;" mucks with the stack trace when it's not supposed to do that.

CLR semantics are frozen as far as C# is concerned.

Well huh...

I appreciate the further information, I did try this myself, and the difference is more clear now. The exception object had the StackTrace with the right info, but the debugger highlights the throw; line.

If the Exception.StackTrace has all the juicy details, why on earth not break there?

Yes, I was certainly thinking about the information available in the exception object itself. It's odd that it's set up this way, but I get it makes sense semantically, if other handler code has run, you need to trace things back yourself probably with a debugging step-through session, or turn on 'first chance exceptions' to get the most 'on the ground' information.

To break immediately on an exception before handlers are invoked: http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

In the spirit of learning, Thanks for your contribution!

Yup, as I said, the problem is crash dumps. If this only affected debugging it would be a minor annoyance, but it destroys information in client crash dumps which get delivered by Watson, effectively making dumps useless.

Exception filters run before the stack is unrolled, so if you crash your process in an exception filter the stack is preserved.

I think it depends on what you think "preserves" means. See here [1]:

    If the exception was rethrown in a method that is
    different than the method where it was originally
    thrown, the stack trace contains both the location
    in the method where the exception was originally
    thrown, and the location in the method where the
    exception was rethrown

Putting aside same method/different method, the original stack trace is preserved, but StackTrace is augmented with the location the exception was rethrown.

There's also a code analysis warning for misuses of throw that uses "preserve" in its title [2].

It says in your profile that you work on Roslyn and I imagine you're familiar with how the exception syntax works with the CLR, so maybe you know something I don't know.

[1] http://msdn.microsoft.com/en-us/library/system.exception.sta...

[2] http://msdn.microsoft.com/en-us/library/ms182363.aspx

It says in your profile that you work on Roslyn and I imagine you're familiar with how the exception syntax works with the CLR, so maybe you know something I don't know.

I do, actually. :)

See https://news.ycombinator.com/item?id=7542701.

Reply on news.ycombinator.com