|
I agree. 
You have just been Sharapova'd.
|
|
|
|
|
PIEBALDconsult wrote: That's dreadful. 
The feature, or the sample? 
|
|
|
|
|
|
Duncan Edwards Jones wrote: time will tell?
I don't see myself to be using any of those in near future except "nameOf" and "await in catch and finally".
You have just been Sharapova'd.
|
|
|
|
|
Agent__007 wrote: "await in catch and finally".
I don't feel the article linked articulated that one well - I shall look it up..certainly error handling is something that needs fixing in async code.
|
|
|
|
|
|
Does anyone find "using static" to be helpful?
If yes then in what circumstances?
I just can't find any reason to use it... even in that very common example ("using static System.Console", which everyone that has posted a C# 6 feature used, I find it's much worse to read it in this manner.
There are some nice features, like Auto-Property initializers it could be helpful for creating a readonly properties, but the only extremely helpful thing (at least to me) is the introduction of nameOf...
|
|
|
|
|
I can´t imagine using it for Console.WriteLine or something, but I think importing extension methods from a class instead of a namespace makes much more sense. Like:
using static System.Linq.Enumerable;
|
|
|
|
|
I see what you mean, so for example if we have one large Extensions namespace with this we could clarify or emphasise exactly which extensions we are using.
Well that could be helpful.
Thanks for the reply.
|
|
|
|
|
Only as far as the developer allows.
|
|
|
|
|
That's why I separate each of my Extension Methods (with overloads) into its own namespace -- I really can't stand having a whole load of crap brought in when I want only one small piece of crap.
But then I also don't like the implementation of Extension Methods requiring the using directive, and the C# implementation not directly using the Attribute (unlike VB.net).
|
|
|
|
|
I also keep them in separate namespaces, it's much cleaner.
But nevertheless I do recall seeing some huge extension containers and I presume this could arrange a bit those big piles of mess...
|
|
|
|
|
While a lot of these new features do have a valid use, I have reservations about the language being extended with a whole set of new terse operators. If that continues, we may end up with something as unreadable as Perl.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: If that continues, we may end up with something as unreadable as Perl.
 I hate Perl with a vengeance!
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Perl with a vengeance
Isn't that Perl 6? 
|
|
|
|
|
I think the Exception Filters example is a little contrived. You can achieve the same behaviour by simple catching specific exceptions in your catch block.
Here is some code that I have used in my WCF client for handling WCF exceptions.
try
{
}
catch (FaultException<UnexpectedServiceFault> ex)
{
Console.WriteLine("Error occurred: {0}", ex.Message);
Console.WriteLine("service message: {0}", ex.Detail.ErrorMessage);
Console.WriteLine("source: {0}", ex.Detail.Source);
Console.WriteLine("target: {0}", ex.Detail.Target);
Console.WriteLine("stack trace: {0}", ex.Detail.StackTrace);
}
catch (CommunicationException ex)
{
Console.WriteLine("Communications error occurred: {0}", ex.Message);
}
catch (TimeoutException ex)
{
Console.WriteLine("Service has timed out");
Console.WriteLine(ex.Message);
}
catch (Exception ex)
{
Console.WriteLine("Error has occurred");
DumpExceptionDetails(ex);
}Surely this is cleaner and easier to read than using C#6 Exception Filters.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Quote: Static Using Syntax
I'm also struggling to see a good use for this. Maybe if you had a huge number of Console.WriteLine() statements in a block?
Quote: Auto-Property Initializers
I like this. Having to move the initialization to the constructor is one of the things I find mildly annoying about properties.
Quote: Dictionary Initializers
Cleaner looking perhaps, but I don't see how it's supposed to be less error prone.
Quote: String Interpolation
Meh. Combined with nameof() this might make writing a custom ToString() for debug purposes a bit better ( return "{nameof(var1)} = {var1}, {nameof(var2)} = {var2}, ..."; ); but you're supposed to use a different syntax for that instead of abusing ToString() anyway.
Quote: nameOf Expression
You could do this with reflection before but IIRC it was rather fugly. It'd be nice to see if this could make some reflection heavy code I wrote years ago easier to read and less brittle.
Quote: Expression Bodied Function & Property
Yuck! I'm only not doing my giant  [^] here for space reasons.
Quote: Exception Filters
Not sure. His example sucks, but I could see this potentially being useful in other cases.
Quote: Await in a Catch and Finally Block
Sounds useful but I haven't written any async code yet so not sure.
Quote: Null Conditional Operator
I've wanted this for years. The example isn't that bad with the old syntax, but try drilling down through 3 or 4 levels of nullable properties/members and checking at each point. Saying elephant it and slapping a try/catch for null reference exceptions was the least unreadable version if not something you'd want to do in hot loops.
BEST NEW FEATURE EVER!!!!!!!!!!!!!!!!!!!!!!!!!111oneoneone111elventyone11!11
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Michael Crump wrote: throw new Exception(...
No, no, no, no NO!!! 
I wish the authors of the BCL had made the base Exception class abstract, to stop people from doing this.
If you want to throw an exception, throw a specific exception type. In this case, it's a problem with an argument being null, so an ArgumentNullException would be appropriate.
Throwing the base System.Exception class is just lazy, and makes your code harder to call - to the extent that Microsoft had to mess with the exception handling[^] to make catch (Exception) do the right thing.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I used several of this. Then was told my applet had to run on .NET 4.5.1 and had to take them out.
|
|
|
|
|
Most of them are compiler features. So long as you're compiling in VS2015, they should still work even if you're targeting an earlier version of the framework.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Should and do are two different things.
|
|
|
|
|
In Disconnecting Distraction Graham tells how he finally dealt with the incessant distraction of the Internet — he simply disconnected his main computer from the network. The simplicity and possible effectiveness of this really intrigued me.
So, for the past two nights of programming, my own computer has been completely disconnected from the network. But how will I look at cat pictures?
|
|
|
|
|
There are times I feel I need to concentrate on a problem, so I take my laptop somewhere away from such distractions.
The last time was a week ago Tuesday -- though having access to MSDN on my phone was still a big help.
|
|
|
|
|
I would consider the fact that he used the offline documentation – which is the same as the online documentation only hosted on his local machine – as cheating; he's been online while offline. 
|
|
|
|
|
Yes, it is shocking, why on earth hasn't he memorized the entire content of MSDN by now?
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
