Exactly, and I'm fine with that, now, but it doesn't 'feel' right. That's my own cross to bear
string s = "bob"; if(s!=null) Console.WriteLine(bob.Length);
just seems safer.
Sorry, that's just not making sense; maybe you need to come up with a better example, but I can't see it. s can never be null here ... even if it was you'd sure as hell WANT an exception to be thrown, because it's exceptional ... you don't want to hide this
kind of exception.
OK, it appears that some of you never started out coding in ASM, C or C++ because you aren't able to envision a time and place where
1) dinosaurs ruled the planet 2) memory allocations were managed by the developer 3) some of them could fail for more reasons than just 'out of memory'.
Would be a great way to cause your application to fail catastrophically.
It's also evident that from your point of view, failure is simply something that the end user can recover from. This is not the case when working on server software. You don't want your application to fail, you want it to retry.
So, All I'm saying is that I've spent at least 1 decade forcing myself to remember these limitations and when I see
It feels 'wrong' to me because, in the past, it WAS wrong, based on my experience.
I'm quite aware that it isn't wrong, and is, in fact, a simpler way to code.
I really don't have anything more to say about it.