It might be just me, but I like nulls
I mean, I like using null as a way to say "the reference does not have a contet" - meaning the method didn't return a value. That's basically the same as None on your example.
It's not just you. You either have something or you don't, so it's a simple concept. The problem with nulls is that you don't have to think about null cases when implementing routines and so if you don't test your application in such a way that a null path is followed, you might have NullReferenceException waiting behind a number of rocks. This is essentially a way of enforcing that you are explicitly handling nulls, but it does come at a price.
It's not going to be for everyone, but it is an Option (pun intended).
Checking for null is simple step, always marshaling Option is exactly same with few additional lines of code. I never had problem with null, because exception can halt further processing.
In this case, entire chain needs to have special line case of None, and another problem is digging root cause of what failed could be nightmare as you have no idea whether method returned a default or something went wrong.
Yeah, I've read and seen the you-tube where Tony Hoare talks about his Billion Dollar Mistake - and I absolutely agree that a NullReferenceException has no place in production code - That's why c#8 came up with nullable reference types, making standard reference types non-nullable - but I suspect that leaves you with no option of indicating a non-existsing value, and that's when the Option class can really come in handy. Anyways, it's always good to pick up coll new tools, so thanks for the article! :-)
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Reference types can still be null in C#8... they just behave more like value types.
They have to explicitly opt into null.
This is the big problem with null and reference types currently... null is not the same as the type itself, it is a separate type.
All reference types in C# are type unions of the type and null but the language doesn't flow this type unions through our code so it's very easy to overlook.
Yes, that's why the concept is called nullable reference types (though I think it should have been called non-nullable reference types, since that's the big change...)
I think the problem with nulls is that many developers, even well experienced, sometimes forget the simple fact that any reference type might be null, especially if it's exposed to changes outside your class (like a get;set; property for example). In fact, as the years go by I find myself more and more in agreement with SO Legend Jon Skeet - as often as you can, make your types immutable. Of course, that doesn't prevent the need for null validations, but at least inside your own types you can be safe from nulls (and other unexpected behaviors).
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Ya, strict constructors, guard clauses, and immutable state (or at least protected invariants) can go a long ways towards evicting null from your codebase (except where it's appropriate, of course).
If we take an Onion architecture approach for our application, and guard against nulls on the outside of our domain, then we can be safe from it within our business logic, which is where we typically have issues with null.
I like that there are many different ways to protect against or at least carefully handle the case of reference types with null values.
That's typically what I gravitate towards - validating on public methods in public classes - then farming things out to private methods or internal classes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It might be just me, but I like nulls
I mean, I like using null as a way to say "the reference does not have a contet" - meaning the method didn't return a value. That's basically the same as None on your example.
It's not just you. You either have something or you don't, so it's a simple concept. The problem with nulls is that you don't have to think about null cases when implementing routines and so if you don't test your application in such a way that a null path is followed, you might have
NullReferenceExceptionwaiting behind a number of rocks. This is essentially a way of enforcing that you are explicitly handling nulls, but it does come at a price.It's not going to be for everyone, but it is an
Option(pun intended).Checking for null is simple step, always marshaling
Optionis exactly same with few additional lines of code. I never had problem with null, because exception can halt further processing.In this case, entire chain needs to have special line case of
None, and another problem is digging root cause of what failed could be nightmare as you have no idea whethermethod returned a default or something went wrong.I really love the conversations this thread sparked. I'm really enjoying seeing the perspectives the community has to bring on quality in general.
Yeah, I've read and seen the you-tube where Tony Hoare talks about his Billion Dollar Mistake - and I absolutely agree that a NullReferenceException has no place in production code - That's why c#8 came up with nullable reference types, making standard reference types non-nullable - but I suspect that leaves you with no option of indicating a non-existsing value, and that's when the
Optionclass can really come in handy. Anyways, it's always good to pick up coll new tools, so thanks for the article! :-)Reference types can still be null in C#8... they just behave more like value types.
They have to explicitly opt into null.
This is the big problem with null and reference types currently... null is not the same as the type itself, it is a separate type.
All reference types in C# are type unions of the type and null but the language doesn't flow this type unions through our code so it's very easy to overlook.
Yes, that's why the concept is called nullable reference types (though I think it should have been called non-nullable reference types, since that's the big change...)
I think the problem with nulls is that many developers, even well experienced, sometimes forget the simple fact that any reference type might be null, especially if it's exposed to changes outside your class (like a get;set; property for example). In fact, as the years go by I find myself more and more in agreement with SO Legend Jon Skeet - as often as you can, make your types immutable. Of course, that doesn't prevent the need for null validations, but at least inside your own types you can be safe from nulls (and other unexpected behaviors).
Ya, strict constructors, guard clauses, and immutable state (or at least protected invariants) can go a long ways towards evicting
nullfrom your codebase (except where it's appropriate, of course).If we take an Onion architecture approach for our application, and guard against nulls on the outside of our domain, then we can be safe from it within our business logic, which is where we typically have issues with
null.I like that there are many different ways to protect against or at least carefully handle the case of reference types with
nullvalues.That's typically what I gravitate towards - validating on public methods in public classes - then farming things out to private methods or internal classes.