The new ?. Operator in C# 6
-
Need to provide a link
New version: WinHeist Version 2.1.1 new web site. When you are dead you don't know it, it's only difficult for others. It's the same when you're stupid.
-
Bullshit.
-
Nope, it is not even my favorite update in C# 6; also hiding NullReferenceException is (IMO) not a very great update. My favorite update is the default values for getters and setters. Also maybe you wanted to link the "Quote" text to this hyperlink: http://www.volatileread.com/Wiki?id=2104[^]
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
Anybody that writes stuff like this:
userManager.CurrentUser == null ? null :
(userManager.CurrentUser.GetRole() == null ? null :
userManager.CurrentUser.GetRole().Name);Or it's
.?shorthand, should be summarily shot. If you have to do all these null checks in order to get the name of the role, then you have absolutely done something very very wrong. And in general, whenever I write code that checks for null, the first question I ask myself is, "WTF am I writing this? I better have a damn good reason." MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Anybody that writes stuff like this:
userManager.CurrentUser == null ? null :
(userManager.CurrentUser.GetRole() == null ? null :
userManager.CurrentUser.GetRole().Name);Or it's
.?shorthand, should be summarily shot. If you have to do all these null checks in order to get the name of the role, then you have absolutely done something very very wrong. And in general, whenever I write code that checks for null, the first question I ask myself is, "WTF am I writing this? I better have a damn good reason." MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Unfortunately I have the displeasure of using an API where that would be a minor help. :sigh:
-
Anybody that writes stuff like this:
userManager.CurrentUser == null ? null :
(userManager.CurrentUser.GetRole() == null ? null :
userManager.CurrentUser.GetRole().Name);Or it's
.?shorthand, should be summarily shot. If you have to do all these null checks in order to get the name of the role, then you have absolutely done something very very wrong. And in general, whenever I write code that checks for null, the first question I ask myself is, "WTF am I writing this? I better have a damn good reason." MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Marc Clifton wrote:
"WTF am I writing this? I better have a damn good reason.
A "damn good reason" could be that you will have no control over the code/behavior of other people who will use/abuse your code ! Or, your code may access resources/data/feed you have no control over which could be null. I would distinguish between cases where: 1. checking for null is a "benign" requirement, like checking the result of a TryParse call 2. cases where checking for null means something may be "wrong" but you still want to continue for example: when your program depends on an externally supplied object which you have no control over. 3. cases where checking for null is essential because if the result is null then there is something totally "wrong" with the current state, and you do not want to continue. In the third case, I would throw an error. By the way, I recall reading comments on a StackOverFlow thread claiming that using the Ternary operator is extremely slow compared to using 'if/else. See: [^] cheers, Bill
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
-
Nope, it is not even my favorite update in C# 6; also hiding NullReferenceException is (IMO) not a very great update. My favorite update is the default values for getters and setters. Also maybe you wanted to link the "Quote" text to this hyperlink: http://www.volatileread.com/Wiki?id=2104[^]
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Afzaal Ahmad Zeeshan wrote:
hiding NullReferenceException is (IMO) not a very great update
It's not hiding a
NullReferenceException; it's checking each level of the expression fornull. In other words, this:DateTime? dateOfBirth = user?.Profile?.DateOfBirth;
is equivalent to this:
// Look, ma - no exceptions!
DateTime? dateOfBirth = user != null && user.Profile != null ? user.Profile.DateOfBirth : default(DateTime?);not this:
// Seriously, don't do this!
DateTime? dateOfBirth;
try
{
dateOfBirth = user.Profile.DateOfBirth;
}
catch (NullReferenceException)
{
dateOfBirth = null;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer