Hello, everybody
Welcome to the webinar
Today we're gonna talk about NULL references, NULL pointers
Basically, NULL references
In object-oriented programming
And my main message today will be...
I'll try to convince you that NULL references is something really bad in object oriented programming
This is something that has to be avoided at all costs
So, it's not what I'm gonna discuss when it's good to you, NULL references when it's not good to you, it's doing bad
Instead, I'll try to convince you that
In general, the presence of NULL references in OOP is something, which is totally bad and wrong and bad practice
First of all, let me show what NULL reference is, just to introduce you to the problem
Let me share the screen with you
Here's the piece of code
And this is a simple method in an object, which, as you see, accepts the name of an employee
And it's trying to find the ID of its employee in a database
It's a primitive example
If the ID equals to zero, than the method returns NULL instead of an employee
And, if actually the ID...
Maybe you can do it like this
If it's less than zero
For example, it's like an indicator of the database didn't find anything
and then returns NULL
And, another case, in a success, like something was found in the database
It actually returns the actual instance of an employee
I'm sure you've seen this in many software solutions
In many places in your software or open source software
People use it everywhere
This is what is considered to be wrong
And specifically this line is wrong
So, instead of returning an instance of employee, we return NULL
Which is not an object
Which is some specific thing in OOP
And it exists in many object oriented languages
And I'm trying to argue that it shouldn't be used
So, I'm not the only one who's saying that
There are many articles and presentations, and some blog posts about that
And the main thing, what people are saying about why it's wrong or why it may be considered wrong
The first, the main argument about that is that it may cause many exceptions
NULL pointer exceptions in the code, which is actually using this function
Let's take a look at this
For example, I'm doing getByName
And I give the name
And then I'm trying to get the salary of the person
So, basically, if the object is not found here
If there's actually no employee by the name 'Jeffrey' in the database
Then I will have the NullPointerException over here
So it's not gonna be a massage to me
I will get the start trace which will contain some kind of strange technical information
Saying 'there's NullPointerException, the object is NULL' instead of an object
We have the NULL and we cannot call the method 'salary'
In this small example it will be more or less clear for me why this NullPointerException is happening
But if the code gets bigger and bigger, then, eventually, these NullPointerExceptions will happen everywhere occasionally
And it will be rather difficult to understand where they are coming from and what's going on
The main argument against this NULL pointer, NULL references is that
it will be technically difficult to trace the problems
because NullPpointerExceptions may happen somewhere, in some places of code
And it will be difficult to trace the causes
That's the main reason
Lots of people are saying that actually, this NULL reference is coming from...
Let me turn it on...
So, that NULL pointers are coming from actual procedural programming or even old C programming
where actually people were dealing with pointers
This is not what we have in modern languages
like Java, Ruby, or Scala, for example
We won't deal with pointers directly
We work with objects
But this NULL was introduced in the languages, which were using pointers
A pointer is actually the location of some object in memory
And the pointer is just a few bytes which are saying where I can find the object
And what's the address of this object
So the NULL was actually a zero
Like, all of this bytes, for example, four bytes, or 8 bytes
which are supposed to contain the location of an object
The contain zeros everywhere
Which is supposed to be the indicator for the user of this pointer that actually there's nothing in there
Don't go to this memory place and don't try to find anything there because there are just zeros everywhere
And it means that the pointer you have is actually not a pointer, but a place holder for a pointer
So you, as a client, as a user of this program...
...are supposed to know that zeros means something different from normal numbers
It is your problem to understand how to interpret the pointer I give to you
You ask me for the location of this employee, for example, and I give you the pointer
And you should know, if I give you zeros, then there's no employee
Don't go there, don't look at this memory address by this zero, because there's nothing in there
But people sometimes forget about that, they don't check for the zeros
They just go to this memory and they check what's there
And they get an exception
They get an exception, some sort of crashes
And a lot of malware and a lot of viruses
They were designed like old viruses
The viruses we get long time ago
They were designed, basically, they were relying on this fact
that some software forget to check the pointers
And they can eventually go somewhere, where there's nothing in there
So, this whole situation with managing pointers and using zero pointers
They kind of cause many technical problems
This is what the arguments are against these NULL references
And asking people not to use them
But this is not what I am gonna say today
This is not my main point
But let me give you a few alternatives before I give you my arguments
So, basically, there's a number of...
I know three possible alternatives to using NULL pointers, NULL references
When you can't actually find the employee
So when you look into the database
and you actually can't find anybody there
So what can you do?
The first option is
Instead of returning NULL
The first option is, return the so-called NULL objects
Or, actually, the first option is to form an exception
That's gonna be the first option
So I can throw a NewEmployeeNotFoundException
And then I can say something like, you know
'I'm sorry, but the employee is not found'
Something like this
So, in this case if the client is getting the same as we were getting before
And it's time to... The client of mine, he's trying to get the salary
Then the exception he will get here, actually
So he will not even go to the salary
Before it will happen here
And the exception will be raised
And the whole situation, the whole software, which is trying to do something with this employee
to print the salary and change the salary
The whole software will crash and the user has to do something about it
That's the first approach
The second one is to return a so-called NULL object
For example, let's say
new Employee, let's say, noEmployee
So, this class implements the employee interface
But it implements it not the way...
Let's say, the employee is the interface, and we have RealEmployee here
And there's NoEmployee here
So they are two different classes, which actually implement the interface 'Employee'
But they do it differently
This one actually implements it the right way
And makes sure that this employee has the salary and knows what to do with the salary
And it's actually a real class
This is a NULL object, which doesn't know...
Which behaves differently, which behaves like the employee is not found
So, in this case, let's say, I just get the name 'Jeffrey' and I don't ask for the salary
I just get the object by the name Jeffrey and then I exit the software
That's the end of the execution
In this case, there's no failure here, because I got some object, I got some Jeffrey
But there's no Jeffrey
I don't care, because I don't need to do anything with Jeffrey
I just exit the software
I just exit the application and I stop
So that's the NULL reference, the different approach
And also there's one approach, which is kind of popular now
It's called 'optional object'
For, example, I can say, here I return 'optional', which is empty
And here I return NULL, which contains something
So, optional is kind of a container with one or zero elements
So, in this case, if I return GetByName Jeffrey, I don't get that Jeffrey directly
I'm saying something like this, 'optional'
It's in Java, but in other languages they have something similar
So, it's an 'opt'
And then I am saying 'if has something', then I can actually get the salary
'opt', 'Get', and then I get the salary
So, and if there's nothing there, for example, if actually Jeffrey was not found, then I do something
I don't know, I print something like 'sorry'
So, this is the three options I'm aware of
Maybe there are more
But I cannot even imagine what could be besides that
The first option is throwing an exception
The second option is to use the NULL object, which looks like a normal object but behaves differently
And the option number three is return some kind of a holder, container of zero or one object
I honestly think that the option number three, this one, is wrong
It's not a solution for a NULL reference
But the first two options, the exception and NULL object, are the perfect solution
So, the problem exists, like I explained
And the solutions exist
But my main argument, my main reason against this thing is not about technical stuff
It's more about theoretical approach to object oriented design
I think that  NULL reference is something that violates the entire idea of encapsulation
And it breaks and actually destroys the trust to the objects we are working with
And it causes...
It's like a disease in the entire application
Which, if we allow it to enter our software, will actually grow and eventually will...
...how do you call it...
..will infect the entire code
So, again, the problem, I think, is that the NULL references, they are...
They are telling me that I should not trust my objects
That's what's happening
So, when I get an object, when I get an employee from this function
And I'm expecting this employee to be an object
Then, I am expecting it to be something, which completely encapsulates what's inside
And I can ask this thing to do something for me
And this thing is supposed to return to me something back
It can throw an exception, it can behave differently
It can crash, it can do whatever, but it's a solid thing
Which I trust
So I know that there are borders of this thing
It encapsulates what's inside
But I trust that this is an object
So when I build my software, I deal with many many different objects
And I trust all of them
By using the word 'trust', I mean that I can rely on them to be self-sufficient
I can rely on them that they will be objects for me
So they will look like objects and they will behave like objects
When I'm getting something which is not an object, then my entire thinking is changed
I start to think differently
I start to suspect all of my objects, all of the variables, which I'm using, all the things, which I'm working with
I'm starting to suspect that they are not good enough
That they are not objects anymore
They can be something else
I'm getting an employee, but I suspect, like 'Hey, maybe it's not an employee anymore'
Maybe it's something else, maybe it's NULL
Which is gonna crash when I just start to touch it
But it's not gonna crash because there's some object inside of it
Because it decides so
But it's gonna crash on my way to it
So, basically, again, it breaks, it makes me...
It makes me think that the stuff I'm working with - the objects, the elements, the items I'm dealing with
They are not real objects, they are not following the contracts I'm expecting
They are not objects anymore
It's similar to scalar types in Java, for example
In Ruby, we don't have that
But in Java we still have an object, which is an employee, for example
And still, for example, we have the salary of this object
Which can be a number, we can integer number
Which is just a number, just a scalar type
It's not an object, I cannot call any methods on it
It's something which is different from an object
In Java we have, like, two types of citizens
We have objects and we have scalar types
This long double float, integer, boolean 
So there are two different kinds of citizens
And also we have the NULL
The NULL is the creature number three of a type number three
Which is kind of a messy situation
It leads to the situation, where I, as a developer, am loosing the trust in the items I'm dealing with
So instead of building the software and relying on these elements
I have to always check, what do I have
Because in case of numbers, the problem was solved in Java
Because there's automatic boxing and unboxing
So when you return to me the salary of an employee
And this salary is actually a number, so an integer
Then I'm trying to use it as an object
Then it's gonna be like some kind of boxing will happen
In Java it will automatically be converted to an object type 'Integer' with the capital 'I'
But in case of NULL, I always have to check what's there, what did you return to me?
Did you give me back the proper employee?
Or you gave me back the NULL?
And because of this distrust, because of this dualistic situation
I always have to remember which way to go
I always have to distrust you as a provider of objects for me
I  have to be careful
And these extra checks, extra validations will eventually...
..like a disease, like an infection, will cover the entire application
Because I will have to check it everywhere
My distrust, my attitude towards these items I'm dealing with will eventually be spread across the entire code
And my functions, they will get longer and longer
Instead of just getting an object, and asking the salary, and using the salary
I will have to get an object
Check whether it's NULL or not
And then do something, and then get the salary
And then the bigger function, which is bigger than that
I have to remember that the salary also may be NULL, may be not NULL
So this 'if NULL' or 'if not NULL' will be everywhere
And this is completely against the object thinking, against the object-oriented mentality and paradigm
That's kind of my point
So the technical issues, which are the main argument...
I don't think it's really that strong, because if you just go to the technical level, and say...
This is what I actually got on my blog post I made a few of months ago
The main point people were expressing in the comments, they were saying that
What's the difference actually between getting the NULL-object and getting the NULL as a NULL
You still have to check sometimes whether it's an object, whether it's a NULL
So technically it looks very similar
'If ... then ... else' comparisons
And on the technical level I agree with these counterarguments
People saying that it's just sometimes more convenient to use NULL
And there's nothing wrong with using NULL sometimes
Because it's just the stuff we're used to
And even if we replace it with NULL-objects or exceptions
It's not gonna change a lot in the code
I agree with that
But it changes a lot on the bigger scale
It changes a lot if we look at the attitude we have to the code we write
Because if we'd start to get used to NULL, and we all are
Look at the open-source stuff we have around us
Everybody is using these NULL references
Everybody is using this approach
And we are used to that
We just know that we have to expect NULL
Look at the Java standards of classes and libraries
Many of them document the situation
They say, we're gonna return you the list of files, for example, in the folder, or you get the NULL
If there is NULL files and there's no folder
So it's like a standard situation, which Java itself encourages us to use
Encourages us to think that way
And I get this counterargument
People saying what's the point, why do we need to get rid of this NULL
It's so technically convenient
It is technically convenient sometimes
But conceptually and theoretically
It's something, which is gonna destroy your deign, your architecture of the application
If you let it happen in your code
So it will eventually affect the way you think
And the way you think will affact your software
So if you think about objects and NULLS, then you're not thinking about OOP anymore
You're not object thinking anymore
You're thinking like the C programmer 20 years ago
Like this is the pointer, and the pointer may be zeros, because there's nothing in memory
But in object thinking you don't think about memory and pointers
You think about objects, which are like living organisms for you
Like some living creatures
Which are not necessarily located in memory
You don't think about memory anymore
You think about objects, and calls to them and messages to them, and their reactions
But NULL doesn't have any reaction
It's not an object, it's something which is from a completely different class
Completely different world
It's not from object-oriented world
It's from procedural twenty-years ago type of thinking and programming
So that's my kind of argument
It's not about technical things
Technically NULL has nothing wrong, I think in just using it here and there sometimes
But conceptually it's very wrong
That's what I wanted to say
And here I'd love to hear your questions
You can start posting your questions
But I have a few questions, which were asked on the blog
And I want to answer them
Some of them are quite interesting
The first question is, people are saying that...
That's the question I got
Some classes, in Java, for example, they are just not suitable for making NULL objects
For example, the string class
It's final
So the string in Java is just a final class
It's not an interface
So when the method is actually supposed to return a string
There's no option to return a NULL string or a NULL reference
It just has to return string or something else
So there has to be some other option you return
In this case, that's a valid concern, and it's a big flaw in Java design
It's a defect we have in the entire language design
For some reason, they made some objects final, some classes final
And there's no way to actually use them in the proper object oriented way
These are very solid structured which are final
Which are not supposed to be extended, which are not supposed to be re-implemented by somebody else
So my answer here is that it's just a misfortune of what we have
And sometimes if you really want to do your design right
Sometimes you may need to re-implement some of the really fundamental basic Java or your language constructs
For example, if you need a function which will return  a name, for example, of an employee
And in some cases there's no name of an employee
And you still want to be able to return something
It has to be like string, like a text
Then introduce your own interface, your own class called 'text
And then you will have the normal text, and then you will have the NULL text
Which will actually decorate and wrap the string thing
The string class in Java
So my answer here is that Java is not perfect
Java is not a pure object oriented language
It does have many flaws and many defects in terms of object thinking
So it wasn't designed as a language for pure object software
And that's why they have this problem
But it doesn't mean that we should make compromises
And that we should develop the software in the way Java tells us to do
Java is just an instrument
Which helps us to put our thinking into...
To help us to convert the way we think
To the way computers can run
Java is just an instrument
Which helps us to translate our object thinking into the way a computer can understand it
If Java is not a perfect translator
And it is not the perfect translator
Then let's just change it, let's just improve it
But let's not change our thinking to the way the translator can understand it
Because that will only do some bad things for us
Our thinking will be affected by the way people thought 20 years ago when they invented Java
And their thinking was kind of wrong in many places
So we should think in a right way
And then just adapt Java for us
Not us for Java
That's what I'm saying
It's possible, Java is a quite flexible language as well as other languages, like Ruby, or Scala, or...
Like popular object languages
So here's my answer
Yes, sometimes it's not possible to use NULL objects everywhere
But if it's not possible, let's make it possible
But don't make compromises and never use NULL
That's the point, never ever
So if you see they are in your code, it's like an indicator that you're doing it wrong, that's it
There's no gray area
It's just black and white, that's my point
So if you use NULL, the code is wrong
It needs to be refractured
It needs to be changed
Even though Java is actually not encouraging you in this particular place
To not use the NULL
You have to be stronger than Java
That's my point
Another question is also quite interesting
But it kind of resonates with the things I said before
People are saying that NULL is fast and exceptions are slow
So when I return NULL, it's just...
And then I let my clients check it
It's much faster than throwing an exception
And letting my client catch the exception and do something about it
So if in this example with the employee
I...
Let me show you the code again
Here
So, if I...
Here's the code
And throw here an exception
I say, 'NoEmployeeFoundException'
For example
And then if it's found, I return a realEmployee
And here's the client
So the client, in order to deal with this stuff, will have to do something like that
He has to getByName 'Jeffrey', and then he has to catch that exception
Then do something about it, I don't know
Print
This is one code
And that's another code
If I would be returning NULL, it would look completely different
I would say something like this
Write it like this
And another 'else' there
GetByName, and then I do, I don't know
And I am saying Jeff...
Print all
So, definitely, obviously, the code here is way faster, than the code here
It is faster
Because every time we throw an exception here
Any exception thrown by Java or any other language
Actually takes a lot of effort for the compile, for the run-time machine
To collect some information about what was the cause of the exception
Where it was thrown
To build a stack trace
It needs to prepare the information
To stop the execution, the normal flow
To go to the exceptional flow
And just to print the text
So all we do here is just print the text
We do a lot of work, we ask our computer to do a lot of work
To catch this exception, to stroll here, to catch it here, and then just print one line
Here it's way faster
So we just say
If it's NULL, it's really fast comparison of the pointer
Exactly, this is the pointer
This comparison will actually go deeper into the implementation of this object 
And see whether it's a real object or it's a pointer, which is a NULL
And then we'll print something
Otherwise, we'll use 'the salary'
So technically, definitely, this is faster
The second example is faster
Like I said before
The speed of execution, the speed of the performance of the software
is a way less important characteristic of a modern software than the maintainability of it
I'm 100% sure that I'm right here
No matter how fat your software is, how high its performance is
The most important thing is how maintainable it is
By maintainability, I mean
How easy it is for me, as somebody who never saw your software
to actually look at it and understand what it does, and make changes to it
So the longer it takes for me to actually...
So the longer it takes for me as a developer to actually understand what your software does
And to go through all your logic
The longer this time is
The less maintainable your software is
And maintainability is way more important than performance
So, like in this example
Yes, using NULL in most cases is way faster than using exceptions
It will make the life of a computer easy
But it will make my life more complex, more difficult
As a developer, I will have more problem to understand your software
And more problem to maintain it
Even though it's faster for the computer
So the problem with the computer we can solve
We can buy a new computer
Just a few hundred dollars
Maybe a few thousand dollars, if it's a really big performance problem
But we cannot buy a new programmer
Or we cannot just solve the maintainability issues with a few hundred dollars
I cannot write the software faster
It's not a problem of a few hundred dollars
Now it's a problem of tens of thousands dollars if your software is not maintainable
And programmers, new programmers, or even you in a few months will not understand how it's written
I'm sure it's obvious
So, using NULL, is, like I said, it's the problem, which will...
It's the attitude, which will eventually penetrate, and eventually infect the entire code
It will happen everywhere
If you start using it in one place, you will use it in another place, you will use it here, there, everywhere
And eventually the entire thinking of your software will be NULL-based
So you will base on the assumption that every object may be a NULL
And you will check for NULL everywhere
Or you will have NoPointerException
And you will eventually have the code, which would look like a C code
Which will look like a procedural code instead of object oriented
So my answer here is yes, exceptions are slower
And yes, NULLs are faster
But this is not the argument in favour of using NULL
Especially now
Maybe 25 years ago it was an argument
Programmers were way cheaper and computers were way more expensive
In that case, for every little second people were fighting and trying to make their software extremely fast
Now it's not the case
Maybe in modern applications, like Android or iOS apps the performance is still an issue
But just give it another few years
And this problem will go away
So the performance is less important
And when the software is highly maintainable, and clear, and easy to understand for the developers
It will be easier to solve performance problems as well
That's my answer to this question
I'm ready for your questions, if you have any
So, you have this Q&A section
We already have half an hour talking
We have less than half an hour left
Give me your questions, I'll try to answer
Another thing, which was mentioned on the blog
One guy said, that 'You know what, this returning NULL is something that we are used to
And we are comfortable with that
We've been doing this for years
And this is something that we all understand'
That was the point
So, why changing now the direction, why changing this approach now
If for many years everybody has been understanding how it works
And they are comfortable with the assumption that whatever comes out of a method...
...can be an object, or can be something that is not an object, but instead a NULL
So why should we...
I mean, why do we need to change this attitude and this approach if it's so clear for everybody?
It's like...
We're used to that
That's the question
And my answer here is that
It's definitely true
Definitely true that in many languages we have this NULL, in Ruby we have the NIL
In Ruby, we even have the function called 'nil?' with a question mark
Which you can apply to whatever comes out of whatever
And this function will say NULL or not NULL
SO they actually embedded this stuff into the language as well
The designers of Ruby
It's so convenient and everybody likes it and understands it
My answer here is that, that's true, but it's more sad than good
So this is definitely what we have
This is definitely the mentality of programmers we have now
And it only tells us that the pure object thinking and pure object oriented mentality...
...is something which is not yet incorporated into modern languages, I think
And whether it's good...
I think it's bad and I think it's sad
Because this is the reality we have now
I believe it's gonna be changed in some time
We have to change it
I think now we have kind of a transition from procedural programming 10 years ago which was fast
Easy to understand when you write it, very close to the way computers think
You don't really need a lot of the fundamental knowledge and principles to write the procedural code
You can teach somebody to write a procedure in a few hours
And somebody who just doesn't know programming at all will be able to write this code
The procedural programming is the very easy translator of your thinking to computer thinking
You think, 'OK, you, as a computer, you are just my worker
And I want you to get this number and add another number to it and give me the result'
So I give specific instructions to the computer, which gives me the result
This is the way procedural programming works
Object thinking is different
It makes the distance between the execution platform and the domain area bigger
We are not staying so close to computers anymore
We are way more abstract now
But the languages we have are twenty years old
When it was important and more convenient to stay closer to the computer, the execution platform
So we are still having...
The computers are far from us now
They are all somewhere in the cloud, they are so big and so huge, so we don't need to stay so close to them
But the languages encourage us to stay close
And that's what's gonna happen in the nearest future
We don't need these languages anymore
We need the languages which are helping us to think our way, to think the way we think about the reality
Instead of being us, programmers, actually, engineers, who instruct computers what to do
So my answer is yes, we are used to thinking the way computers think, but we need to change that
Now we have some questions from you guys
Question number one is
Why don't you recommend the optional approach?
Yeah, I was expecting that question
Like I said, there are three approaches
The first one is instead of NULL it's throw exception
The second one is make some NULL object
Number three is optional approach
Optional means the container, which we create...
Inside of the container we package something or nothing
And I give it to you back
I think this is against object thinking as all
As well as NULL reference
It's not even better than NULL reference
What is this container?
It's a pure data structure
Which encapsulates the object
So this container is not an object by itself
It doesn't look like an object
It doesn't work like an object
It's like a temporary memory structure, which holds a real object
So when I'm asking you, 'Give me the employee'
And the name of the employee is Jeffrey
And I'm expecting you to give me the employee
I don't expect any container
I want to get an employee
I want to get an object which I can talk to 
But instead you're giving me something which I need to manipulate with
Before I can actually work with the real Jeffrey
So this manipulation with this container is actually the trouble you're placing on my shoulders
So you're giving me something which is not yet ready to work with
You're giving me something I need to think about
How to manipulate this stuff, how to understand it
It is very close to NULL references
The same in case of NULL
You're returning me something, but I need to remember that I need to deal with it somehow
The same here
I need to check, do you have an employee for me or you don't
It's a solution which is introduced like a replacement for the NULL reference
But it actually is not
It's not a replacement, it's just  a look-like replacement
Because in a pure object world, in a pure object thinking
We're only talking between the real objects
Which represent the real life entities
They are like people
They're living creatures, they talk to each other
In a real world, we don't have containers
Which contain this Jeffrey, for example
I'm not calling a department and saying, 'Hey, I wanna talk to Jeffrey'
And instead of putting Jeffrey on the phone and letting me talk to Jeffrey
They give me some container, which I'm supposed to dig into, and get some Jeffrey out of it
And then talk to Jeffrey
It's contrary to it
This is not how we should think if we're talking about objects
So it's just a solution which is not a solution
That's my understanding
Again, on theoretical level
On a practical level, yes, it works, it's perfectly fine
You get an optional, it's introduced in Java 7
You get this optional, it looks like something which is not NULL anymore
But it's not a solution, it's just a primitive approach to solving the fundamental problem
That's what I think
The next one
Do you have a NULL object for each domain entity in your systems?
In some cases, yes, we do that
In some cases we decided it that way
We is me and people who work with me
But it's only where it's necessary
Because not every object may have a NULL...
Not every domain entity, like you call it, may have this NULL thing
For example, in the case of employee
Maybe it's not even a great idea to return actually the NULL employee if Jeffrey is not found
Maybe in this case I would rather throw an exception
But for example, if we...
So to answer this specific question, I would say, rarely
For domain entities I would create NULL objects in very rare cases
Mostly this NULL objects are good for systems entities
Not domain entities, not like employee, department, car
I don't know, vehicle or something else
Something which is inside the system objects, like identity, file, directory, that kind of stuff
In this case, these NULL reference are very convenient
That's my answer
Another question is
What should be returned by NULL employee method getSalary or getName?
Empty string, or noEmployee, or something else?
Yeah, I understand the question
So, for example, this NULL employee is a NULL object which looks like an Employee
It has the salary, name, and all the other methods, which you can call
But the question is what happens when I call this method
It depends on the situation
It depends
For example, in case of a...
It depends on how you see who is this noEnployee
For example, let's say I'm calling the department and asking for Jeffrey
Like, give me Jeffrey on the phone
I want to get this object, and I want to...
I want to say...
The salary is something which definitely can't exist, if it's a noEmployee object
But, for example...
Let me think what can actually exist...
Okay, let's say the department
I have a department object
And I'm saying, in this department object I have the method, which is called 'findEmployee'
I know the department, it's a software development department
I'm saying, give me the Jeffrey
And there is no Jeffrey there
So it returns me the object, which is noEmployee
And it's not Jeffrey, it's something else
But it's returned from the software development department
So in this object I may have a method, which is called 'department'
So I wanna get back the department
And this method can be perfectly finely implemented
Even though it's a noEmployee
I can still get back to the department
I can still get back an instance of the department
Which returned me the object
So this method is perfectly implemented
But the method 'salary' will throw an exception
The salary method will throw an exception and say, 'Hey, I cannot tell you my salary because I'm noEmployee'
There is no salary here, or there's no name here
But when this happens, the exception, which you will get, will have a proper explanation of what happened
The exception will say, 'You know, you asked for Jeffrey employee
But we didn't find anything, and now you're asking for the salary, this is wrong'
That's what's gonna be the text of the exception
It's not gonna be 'NullPointerException', boom
And then you need to dig into your code and find out where it happened
It will be a properly formatted exception which will say, like I said
'You were looking for Jeffrey employee in the software development department
We didn't find anybody, but now you're asking for the salary'
Again, this exception will help you to understand what's going on and will help you to solve the problem
So, to answer your question
What's gonna be the result of these methods
In most cases, they will throw exceptions
In most cases, there's gonna be exceptions
So, again, I can hear you thinking
What's the difference between the NULLpointerException, or this exception, thrown by these methods
But there is a difference
Because the NULL pointer exception is thrown by the machine
By the Java machine
Not our objects
But something, which is around our objects, something which we don't control
I am suggesting that the exceptions are thrown by us, by our objects
So we are in charge, we control, we encapsulate this behavior
The objects know what to do, the control it
Not the machine, not the Java machine
Not the run-time environment
But specifically my objects, created by myself
And the exceptions will have my text, which I define there
It is very important
That's the difference
So, yes, the exceptions in those cases
But the difference is conceptual
The next question
Doesn't NULL object just delay the failure?
If I want to raise the salary of employees
setNewSalary, where employee is NULL object
How should it behave?
Definitely yes
Of course, the question is, doesn't NULL object just delay the failure?
Yes, the NULL object just delays the failure
Technically
If you're talking about technicality, what's happening on the level of these bits and bytes
Then yes, of course, we just delay the moment when the exception will be thrown
And we control this process, we control this moment of throwing the exception
It's not happening accidentally because I gave you something which doesn't work
I gave you some broken thing
Which is completely against your expectations
But an exception is happening, when this perfectly organized and proper object actually decides to throw an exception
So if you want to raise the salary of an employee, which is the NULL employee
And then you set the new salary
Then it should definitely tell you, 'You know, it's not a real employee
You're looking for an employee, I gave you something
But it's not an employee, so you can't set me the salary
You can do something else with me
But you can't change my salary, because I'm nobody
We have it in my Java Web Framework called Takes
We have the authentication mechanism
We have a class, which authenticates the user, who actually entered the system
And to authenticate this method returns an Identity or it returns a noIdentity
So there's no NULL actual
But there's another identity which is called anonymous
So when you ask me who's entering the system, I can give you two answers
I can give you the real identity, or I can give you something which looks like a real identity, but it's called anonymous
And then it's up to you
If you need to really know who enters the system
You really need to differentiate between the real users and the anonymous users
Then you make this decision, you compare and decide, 'Okay, this is anonymous, this is not'
But if you don't care, if you just get an anonymous identity and you, for example, just continue execution
Log the process, like, yes, this identity just got into the system
And it did something
You don't need to know what the identity was
Real user, or it's anonymous user
We just need to log the execution
Like, identity number one - save the file
Identity anonymous - save another file
Identity number five - save the file
It's gonna be just a long line
For example, you don't care what's inside the identity
Works perfectly fine
But if you wanna go deeper and ask, for example, what's your name 
Then anonymous identity will throw an exception
And say 'no, I'm not a real one'
I'm just anonymous, we don't know the name of this user
Yes, somebody entered the system, but that's an anonymous user, without a name
We control it
That's my point
Another question
Isn't it more adequate conceptually and maybe even easier, throwing an exception in all cases?
In general, I would suggest to use exceptions more than NULL objects
Definitely, of course
I use it in 90% of cases, maybe 95% of cases
I use exceptions, of course
In general, you throw exception as much as possible
The more you throw exceptions in your code
The better you code is, I think, in general
The more brittle, the more fragile your code is
The more frequently it says, 'Something's wrong, I can't continue'
The better the code is
It has to be as fragile as possible
And as much as possible covered with a uni test
That's kind of a conflict of interest
Two approaches, which will make the code higher and better
So, on one side, you make your code brittle and fragile and fail as soon as possible, fail-fast
And on the other side, you try to cover it with the uni-test as much as possible
On this combination the coding goes up
So, in general and conceptually, I'd say that exceptions are much more preferred
But in some cases, like I just gave an example of authentication of a user
So I'm asking you who's the user, and give me the user
Give me the identity which is now using my system
So that will be wrong, if you just throw an exception and say, 'There's no identity'
It's way easier to say, 'There is an identity, but it's anonymous'
So it will be easier for me, instead of catching the exception, thinking okay, there's no exception
And then do something else
I just get an identity from you
But the way I use it, it just depends on me
In most cases, I just don't need to know the name of this user, who's actually using this system
Like I gave you an example with the logging
I just log the type of the user who's using the system
Anonymous - not anonymous
That's it
So...
I would suggest exceptions in most cases, but sometimes NULL objects are conceptually better
Two more questions and we're done
Don't you think that exceptions should only be used in exceptional cases
This is why they were created
But in the example with the employee, if no employee is found
That's a normal situation, not an exceptional one
What do you think from OOP prospective?
Yeah, that's a good question
Yes, I think that...
Yes, definitely, exceptions are for exceptional situations
And we definitely shouldn't control the flow with exceptions
We should not tell our users that, 'You know what, you call this method
And then if I give you something, use it
I can throw this exception if I think something else, I can throw that exception, if I think something else
This is not really a good approach
There has to be one exception usually
In most cases, one exception from methods
And this exception means that something is wrong on the application level
It's kind of a message that the entire application has to stop
Because we hit the place, where something went completely wrong
That's what exceptions are for
So, in this example like I showed, with an employee
Throwing an exception when you ask me 'Get me employee by name'
And I give it to you
You want one specific employee
That's the design of the method, that's the signature of it
One employee, one call, you give me the name of it
So I have to return you the employee, that's my promise to you
If I think that this situation, getting an employee by name
If I have to give you the possibility to be more flexible in this
And not crash the entire application when there's no employee Jeffrey
Then I will give you another method, which will be called not getEmployee, but findEmployee
And then the findEmployee will return the collection of employees found
And this collection will contain one, two, maybe zero items
So you're asking me to find the employee by the name Jeffrey
And I return you the collection of found employees
Maybe it's gonna be one element
And then you will see, okay, if it's empty collection, there's nothing found
If or itArray
If it's something in this itArray, or a collection, then something is actually found
So yes, definitely, exceptions should be not used for flow control
But they must be used for real exceptional situations
Okay, one last question
This webinar is about programming languages
But I wonder how you feel about NULL in SQL and Sequel
Normalizing NULL out of your database can make it more complex, and thus, harder to maintain
That's a good question to think about
Well, in general I think that NULL is a bad idea
But in relations databases, NULL is a part of the relational calculus
And there's different source
There's a different origin of this NULL in a relational database
It's not coming from, like we have here, pointers and location memory
It's coming from inability to match two relations together
So if I select...
For example, I have to decamp this multiplication of two sets, for example
Of two relations, two tables
Then, if they match...
If I find a match, then I put the data there
If I don't find a match, I have to put something in there
There's a strong science behind that
So I  think In Sequal NULL has its perfect place
Because it's a different thing, it's not a pointer, it's not a location memory
It's like an absence of data
An absence of data is a perfectly valid situation in relational calculus 
So it's different things
In programming languages NULL means a zero, basically
It's a zero
Instead of a real pointer to memory, that's where it's coming from
And this is a very old and long time ago expired idea
But in a relational database it's a perfect absence of data
They have the same names
NULL here and NULL there
But they mean completely different things
That's what I think
Okay guys, we're done
It's one hour, thank you for attending
See you next month, it's the first Wednesday of every month at 11 pm Pacific time
Thank you very much
Happy coding!
