It looks like we are able to start up our local API successfully, but before we move on and add in
any more functionality, there's just a very quick side topic I want to visit.
Remember, whenever user runs are Java Command or specifically the server command, we're going to start
up an express server and listen on Port four thousand five by default.
Now, it is incredibly likely that at some point in time, a user might accidentally try to start up
two copies of this serve command on the same exact port.
You and I can simulate that very easily if we open up a second terminal window still inside of our disk
directory and then do another node index such as surf.
So if we do that, we're going to try to start up a second express server, also listening on four thousand
five because there is already a server listening on four thousand five, we end up with this big, nasty
error message.
And the error message, more or less, says that this port is already in use.
So we're definitely displaying an error message here, but this error message is not really appropriate
to show to a user, although there's a lot of stuff inside of you and there's eventually something that
says, hey, this address is already in use if a beginner is trying to use our application.
Well, they're going to see this big old block of text right here.
They might not actually see the real error message right here.
And they might be really confused about exactly what is going on.
They might think that our application is just bad and not really understand how to fix this.
So I think we need to add in some better error handling.
We need to better be able to capture errors like this and somehow print out some actionable advice to
our user on how to fix it.
The question then very quickly becomes, where should we put in some air handling code like that?
Where should we try to capture in air while we are starting up our Seelie and then take the air and
print up some information from the air to the user?
There's two obvious candidates for where to place this code.
The first possible place would be inside of our search function.
So inside of our search function, we could add in some code to say, hey, you know what?
If we unsuccessfully start up this listen process, let's capture that air and display some message
to the user and say, hey, you probably want to run this thing on a different port.
That's option number one.
The other option is to add in some air handling to our server command itself.
So maybe inside of our action function, we could say that if the search function right here throws
an air, we should capture that error and display some message to the user once again to tell them how
to fix this problem.
So out of these two different options, I think that the better avenues are the better approach would
be to add in some air handling code to the server command.
There's a very simple reason for this.
Remember, our Seelie might eventually have many different commands associated with it.
Right now we have just one, but we could very well have many different commands at some point in the
future.
All these different commands can definitely have errors associated with them, in other words, we start
to add in other commands and users start to run those commands.
There's definitely some other errors that might be thrown along the way.
So at the Seelie level, it makes a lot more sense to handle Eyre's inside there because then we can
have some very consistent air handling experience.
We can make sure that for all these different kinds of errors coming out of all these different commands,
we always take the errors and treat them in a very similar fashion.
So we can always print up some very consistent messaging.
We can always print out some very consistent message to the user and help them understand what went
wrong and how to fix it.
If we implement any kind of error handling or reporting to our user inside of our individual packages,
such as local API, like insert inside of the actual search function itself, inside of here, if something
goes wrong, we might print up one error message that says, hey, something's wrong with this port
or some partisan news or something like that, and then print out a really long, detailed error message
or something like that.
Whereas if another engineering team is working on some command that is being executed by some other
package, they might decide to print out all the error messaging in a very, very different fashion.
So it's just a lot easier to have much more consistent messaging to our user if we locate all this error
handling stuff directly in the SEELIE.
So that's pretty much the takeaway.
We're going to inside of our action function with some error handling around calling our serve commands.
If anything goes wrong with calling serve, we're going to capture that er figure out what went wrong
and then print up some message to our user to help them understand what just happened.
OK, so with all that mind, let's take a pause right here and then add in some air handling in just
a moment.