1
00:00:01,540 --> 00:00:05,980
It looks like we are able to start up our local API successfully, but before we move on and add in

2
00:00:05,980 --> 00:00:09,290
any more functionality, there's just a very quick side topic I want to visit.

3
00:00:09,880 --> 00:00:14,800
Remember, whenever user runs are Java Command or specifically the server command, we're going to start

4
00:00:14,800 --> 00:00:18,050
up an express server and listen on Port four thousand five by default.

5
00:00:18,790 --> 00:00:23,560
Now, it is incredibly likely that at some point in time, a user might accidentally try to start up

6
00:00:23,560 --> 00:00:27,220
two copies of this serve command on the same exact port.

7
00:00:27,590 --> 00:00:32,970
You and I can simulate that very easily if we open up a second terminal window still inside of our disk

8
00:00:33,010 --> 00:00:37,660
directory and then do another node index such as surf.

9
00:00:38,970 --> 00:00:44,220
So if we do that, we're going to try to start up a second express server, also listening on four thousand

10
00:00:44,220 --> 00:00:49,650
five because there is already a server listening on four thousand five, we end up with this big, nasty

11
00:00:49,650 --> 00:00:50,340
error message.

12
00:00:51,180 --> 00:00:56,070
And the error message, more or less, says that this port is already in use.

13
00:00:58,570 --> 00:01:02,710
So we're definitely displaying an error message here, but this error message is not really appropriate

14
00:01:02,710 --> 00:01:08,170
to show to a user, although there's a lot of stuff inside of you and there's eventually something that

15
00:01:08,170 --> 00:01:12,640
says, hey, this address is already in use if a beginner is trying to use our application.

16
00:01:12,880 --> 00:01:15,360
Well, they're going to see this big old block of text right here.

17
00:01:15,400 --> 00:01:18,310
They might not actually see the real error message right here.

18
00:01:18,550 --> 00:01:21,100
And they might be really confused about exactly what is going on.

19
00:01:21,370 --> 00:01:25,120
They might think that our application is just bad and not really understand how to fix this.

20
00:01:25,820 --> 00:01:27,990
So I think we need to add in some better error handling.

21
00:01:28,150 --> 00:01:33,220
We need to better be able to capture errors like this and somehow print out some actionable advice to

22
00:01:33,220 --> 00:01:34,510
our user on how to fix it.

23
00:01:36,330 --> 00:01:41,010
The question then very quickly becomes, where should we put in some air handling code like that?

24
00:01:41,400 --> 00:01:46,740
Where should we try to capture in air while we are starting up our Seelie and then take the air and

25
00:01:46,740 --> 00:01:49,360
print up some information from the air to the user?

26
00:01:50,100 --> 00:01:53,490
There's two obvious candidates for where to place this code.

27
00:01:54,340 --> 00:01:57,180
The first possible place would be inside of our search function.

28
00:01:57,900 --> 00:02:01,140
So inside of our search function, we could add in some code to say, hey, you know what?

29
00:02:01,140 --> 00:02:07,020
If we unsuccessfully start up this listen process, let's capture that air and display some message

30
00:02:07,020 --> 00:02:10,289
to the user and say, hey, you probably want to run this thing on a different port.

31
00:02:10,650 --> 00:02:11,610
That's option number one.

32
00:02:12,030 --> 00:02:17,610
The other option is to add in some air handling to our server command itself.

33
00:02:17,970 --> 00:02:22,830
So maybe inside of our action function, we could say that if the search function right here throws

34
00:02:22,830 --> 00:02:27,240
an air, we should capture that error and display some message to the user once again to tell them how

35
00:02:27,240 --> 00:02:28,170
to fix this problem.

36
00:02:28,770 --> 00:02:33,900
So out of these two different options, I think that the better avenues are the better approach would

37
00:02:33,900 --> 00:02:37,010
be to add in some air handling code to the server command.

38
00:02:37,420 --> 00:02:39,020
There's a very simple reason for this.

39
00:02:39,600 --> 00:02:43,950
Remember, our Seelie might eventually have many different commands associated with it.

40
00:02:44,310 --> 00:02:48,330
Right now we have just one, but we could very well have many different commands at some point in the

41
00:02:48,330 --> 00:02:48,750
future.

42
00:02:50,300 --> 00:02:54,800
All these different commands can definitely have errors associated with them, in other words, we start

43
00:02:54,800 --> 00:02:57,900
to add in other commands and users start to run those commands.

44
00:02:57,950 --> 00:03:01,250
There's definitely some other errors that might be thrown along the way.

45
00:03:03,020 --> 00:03:07,490
So at the Seelie level, it makes a lot more sense to handle Eyre's inside there because then we can

46
00:03:07,490 --> 00:03:10,130
have some very consistent air handling experience.

47
00:03:10,430 --> 00:03:14,600
We can make sure that for all these different kinds of errors coming out of all these different commands,

48
00:03:14,780 --> 00:03:17,960
we always take the errors and treat them in a very similar fashion.

49
00:03:18,320 --> 00:03:20,750
So we can always print up some very consistent messaging.

50
00:03:20,960 --> 00:03:25,550
We can always print out some very consistent message to the user and help them understand what went

51
00:03:25,550 --> 00:03:26,660
wrong and how to fix it.

52
00:03:27,290 --> 00:03:32,120
If we implement any kind of error handling or reporting to our user inside of our individual packages,

53
00:03:32,390 --> 00:03:37,670
such as local API, like insert inside of the actual search function itself, inside of here, if something

54
00:03:37,670 --> 00:03:42,110
goes wrong, we might print up one error message that says, hey, something's wrong with this port

55
00:03:42,140 --> 00:03:46,580
or some partisan news or something like that, and then print out a really long, detailed error message

56
00:03:46,580 --> 00:03:47,360
or something like that.

57
00:03:47,750 --> 00:03:53,210
Whereas if another engineering team is working on some command that is being executed by some other

58
00:03:53,210 --> 00:03:57,680
package, they might decide to print out all the error messaging in a very, very different fashion.

59
00:03:58,130 --> 00:04:02,630
So it's just a lot easier to have much more consistent messaging to our user if we locate all this error

60
00:04:02,630 --> 00:04:04,340
handling stuff directly in the SEELIE.

61
00:04:04,970 --> 00:04:06,200
So that's pretty much the takeaway.

62
00:04:06,470 --> 00:04:11,830
We're going to inside of our action function with some error handling around calling our serve commands.

63
00:04:12,140 --> 00:04:16,310
If anything goes wrong with calling serve, we're going to capture that er figure out what went wrong

64
00:04:16,310 --> 00:04:19,910
and then print up some message to our user to help them understand what just happened.

65
00:04:21,589 --> 00:04:25,490
OK, so with all that mind, let's take a pause right here and then add in some air handling in just

66
00:04:25,490 --> 00:04:25,900
a moment.