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.
The problem with null is that it breaks the type system somewhat.
If a functions says that it returns Person, then I can not trust it to do that, because it might return null, so I need to check for it. And I might just forget to check for it.
But if the type system could encode in the type signature that the function might return null, then I can have the compiler fail to compile unless handle the case where there is a null.
The advantage of this is that it makes the entire class of null errors go away because the compiler can check that we handle both cases.
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.
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.
The problem with null is that it breaks the type system somewhat.
If a functions says that it returns Person, then I can not trust it to do that, because it might return null, so I need to check for it. And I might just forget to check for it.
But if the type system could encode in the type signature that the function might return null, then I can have the compiler fail to compile unless handle the case where there is a null.
The advantage of this is that it makes the entire class of null errors go away because the compiler can check that we handle both cases.