I've been programming for two decades now and have been working with .Net since 1.1 - and though admittedly most of the projects I've been working on was small ones, with either just a me as the single developer or a small team of up to four developers - I have to say that personally, I've never thought about null as such a problematic concept. I've had the occasional NullReferenceException here and there throughout my career, but it wasn't so often as I've heard other developers complaining about...
Personally, I think I would prefer to see syntactic sugar for defensive coding over non-nullable reference types - because while I agree defensive coding is cumbersome and somewhat of a pain to write (especially since you want to instantiate and throw the ArgumentNullException from the each method so you're forced to repeat yourself) - I still find the option of returning null from a method (like, if you didn't find what you're looking for in the database, for example) quite attractive and easy to handle. I know you can implement (or download a nuget) the Maybe Monad to avoid having to use null), but that seems to be a bit more cumbersome to work with.
Please do not return null because your query did not find anything.
Null is the absence of information. It's the abbreviation for "I don't know what happened". Please don't put meaning to it. Do not return null in any case. Throw exceptions, return error objects or whatever, but do not return null. Null is contains zero information and has no meaning.
I would never suggest throwing an exception if something wasn't found in the database. that's an entirely non-exceptional situation and throwing an exception because of that would be, IMHO, a perfect example of a vexing exception.
(Even if you store information in a database that is needed for the software to run, such as configuration information - even in this case, I would rather handling the lack of critical information in code, rather then throwing an exception).
Also, Null in c# (like Nothing in Vb.Net) is not "the absence of information" - it's a reference that doesn't point to an instance. What you are referring to might be Null in the world of relational databases, where it is most accurately described as an unknown value.
To me, having a method returning null when data wasn't found makes perfect sense - because the data was not found, an instance of the return type could not have been initialized, and therefor you get back null.
This can be replaced by using something like the Maybe Monad (click here for a long but good explanation), but IMHO that's a more complicated solution to the same problem.
I mean, you'd have to check if the Maybe is none or if it contains a value anyway, so you might as well check if the reference is null - with no extra complication to your codebase.
A Reference that points to nothing is the absence of information. There is literally nothing (read: no information) behind the pointer.
For a database query neither null/Null nor an exception are the right tool. An empty List would be. If you query for exactly one Object (like with the id), null/Null can be an option. So could an Exception, as if you have an ID, there better be an object for this. This depends on the context.
Problem is: Null/null returns are also often misused. It is still dangerous and clutters code. For me it is a 'Do not use lightly'. I have to have a reason for using something so dangerous.
True, if you're selecting a list of object, an empty list (or an IEnumerable) would be the obvious choice of what to return when you find nothing that matches the search criteria. For a search of a single object, I see no problem with null. I guess we can simply agree to disagree.
I still find the option of returning null from a method (like, if you didn't find what you're looking for in the database, for example) quite attractive and easy to handle.
I don't think this is being contested by anyone. However, if a method returns a string, I have no choice but to read the documentation or source code to know whether null is a legal return value. The thing I like about nullable references is that string? makes it 100% clear that null can and will happen.
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.
I've been programming for two decades now and have been working with .Net since 1.1 - and though admittedly most of the projects I've been working on was small ones, with either just a me as the single developer or a small team of up to four developers - I have to say that personally, I've never thought about
nullas such a problematic concept. I've had the occasionalNullReferenceExceptionhere and there throughout my career, but it wasn't so often as I've heard other developers complaining about...Personally, I think I would prefer to see syntactic sugar for defensive coding over non-nullable reference types - because while I agree defensive coding is cumbersome and somewhat of a pain to write (especially since you want to instantiate and throw the
ArgumentNullExceptionfrom the each method so you're forced to repeat yourself) - I still find the option of returning null from a method (like, if you didn't find what you're looking for in the database, for example) quite attractive and easy to handle. I know you can implement (or download a nuget) the Maybe Monad to avoid having to use null), but that seems to be a bit more cumbersome to work with.Please do not return null because your query did not find anything.
Null is the absence of information. It's the abbreviation for "I don't know what happened". Please don't put meaning to it. Do not return null in any case. Throw exceptions, return error objects or whatever, but do not return null. Null is contains zero information and has no meaning.
I would never suggest throwing an exception if something wasn't found in the database. that's an entirely non-exceptional situation and throwing an exception because of that would be, IMHO, a perfect example of a vexing exception.
(Even if you store information in a database that is needed for the software to run, such as configuration information - even in this case, I would rather handling the lack of critical information in code, rather then throwing an exception).
Also, Null in c# (like Nothing in Vb.Net) is not "the absence of information" - it's a reference that doesn't point to an instance. What you are referring to might be Null in the world of relational databases, where it is most accurately described as an unknown value.
To me, having a method returning null when data wasn't found makes perfect sense - because the data was not found, an instance of the return type could not have been initialized, and therefor you get back null.
This can be replaced by using something like the Maybe Monad (click here for a long but good explanation), but IMHO that's a more complicated solution to the same problem.
I mean, you'd have to check if the Maybe is none or if it contains a value anyway, so you might as well check if the reference is null - with no extra complication to your codebase.
A Reference that points to nothing is the absence of information. There is literally nothing (read: no information) behind the pointer.
For a database query neither null/Null nor an exception are the right tool. An empty List would be. If you query for exactly one Object (like with the id), null/Null can be an option. So could an Exception, as if you have an ID, there better be an object for this. This depends on the context.
Problem is: Null/null returns are also often misused. It is still dangerous and clutters code. For me it is a 'Do not use lightly'. I have to have a reason for using something so dangerous.
True, if you're selecting a list of object, an empty list (or an IEnumerable) would be the obvious choice of what to return when you find nothing that matches the search criteria. For a search of a single object, I see no problem with null. I guess we can simply agree to disagree.
I don't think this is being contested by anyone. However, if a method returns a
string, I have no choice but to read the documentation or source code to know whethernullis a legal return value. The thing I like about nullable references is thatstring?makes it 100% clear thatnullcan and will happen.