1
00:00:06,630 --> 00:00:07,110
Hello.

2
00:00:07,770 --> 00:00:15,180
In this video, we will talk about Question 13, why cut exceptions, almost always a bad idea.

3
00:00:15,300 --> 00:00:20,580
And when it is not touching an object of system exception type.

4
00:00:20,700 --> 00:00:27,000
So the most general type of exceptions in C-sharp is almost always considered a bad idea.

5
00:00:27,450 --> 00:00:32,020
This is because when you cut an exception, you should handle it appropriately.

6
00:00:32,100 --> 00:00:37,650
But if you don't know what the exception type is exactly, how can you know how to handle it?

7
00:00:38,230 --> 00:00:40,080
Let's consider this method.

8
00:00:40,380 --> 00:00:45,690
It works similar to the parameters first or default method from LINK.

9
00:00:46,200 --> 00:00:52,290
It returns the first month from the collection, but if the collection is empty, it returns the default

10
00:00:52,290 --> 00:00:54,510
value in the cut gross.

11
00:00:54,540 --> 00:01:00,000
We cut an exception and we print the information that the collection is empty.

12
00:01:00,390 --> 00:01:06,990
But other exceptions not related to the emptiness of the collection can be thrown in the thread close

13
00:01:07,140 --> 00:01:13,370
like out of memory exception or Stack Overflow exception for those two types.

14
00:01:13,410 --> 00:01:16,710
It's extremely hard to predict when they will happen.

15
00:01:17,100 --> 00:01:20,400
Of course, in a healthy application, they shouldn't happen at all.

16
00:01:20,550 --> 00:01:23,940
But we don't know how the rest of this application looks like.

17
00:01:24,300 --> 00:01:30,480
It might be the case that the cut close will cut out of memory exception, and it will handle it with

18
00:01:30,480 --> 00:01:34,950
the false message saying that the collection is empty, even if it wasn't.

19
00:01:35,400 --> 00:01:36,540
The true problem?

20
00:01:36,720 --> 00:01:40,830
The lack of memory in the application would be swept under the rug.

21
00:01:41,340 --> 00:01:46,350
Because of that, we should always catch a specific exceptions as possible.

22
00:01:48,670 --> 00:01:55,210
The first method that we use here draws invalid operation exception when the collection is empty, so

23
00:01:55,210 --> 00:02:00,100
handling this exception here is most appropriate for the same reasons.

24
00:02:00,280 --> 00:02:05,230
We should always throw us specific exceptions as possible from our own code.

25
00:02:05,590 --> 00:02:07,420
Let's consider this method.

26
00:02:09,520 --> 00:02:12,700
Throwing an exception here is not a good idea.

27
00:02:13,000 --> 00:02:19,360
We should be more precise when choosing an exceptional type, so it fits the situation when the first

28
00:02:19,360 --> 00:02:20,530
exception is strong.

29
00:02:20,710 --> 00:02:24,640
The problem lies with the new collection passed to the average method.

30
00:02:24,820 --> 00:02:25,840
So are humans.

31
00:02:25,840 --> 00:02:28,060
No exception is a perfect fit.

32
00:02:30,160 --> 00:02:36,370
In the second case, when the collection is not known, but empty, invalid operation, exception or

33
00:02:36,370 --> 00:02:39,340
argument exception seem most appropriate.

34
00:02:42,220 --> 00:02:48,700
Exceptions give us priceless insight into what problems do we have in our application, and we should

35
00:02:48,700 --> 00:02:54,790
never mask them with some generic handling that will hide the detailed information they carry.

36
00:02:55,240 --> 00:02:59,440
So is it ever appropriate to have the exception clothes?

37
00:02:59,650 --> 00:03:03,220
Well, it is in two specific scenarios.

38
00:03:03,880 --> 00:03:07,840
The first one is the global cut block in our application.

39
00:03:08,410 --> 00:03:11,080
This is the last resort of exception handling.

40
00:03:11,620 --> 00:03:17,760
If something totally unexpected happens and there is no way of continuing the applications work after

41
00:03:17,770 --> 00:03:24,160
that, we should simply show the exception to the user and store it in some logs after the user reached

42
00:03:24,160 --> 00:03:24,850
the error.

43
00:03:25,030 --> 00:03:26,560
The application will be stopped.

44
00:03:27,070 --> 00:03:30,700
Let's add a global catch block to this console application.

45
00:03:38,940 --> 00:03:45,330
In this case, we simply to the font color to read, and we printed the exception to the console in

46
00:03:45,330 --> 00:03:51,090
applications with some proper interface, such a global catalog usually shows some error pop up.

47
00:03:51,600 --> 00:03:58,290
Another case when catching any type of exception could be OK is when we don't intend to handle it.

48
00:03:58,560 --> 00:04:05,910
We only withdraw it, possibly log it or add some additional information to it in such a timing application

49
00:04:05,910 --> 00:04:06,910
as ours.

50
00:04:06,930 --> 00:04:13,530
It doesn't make much sense, but in big projects, it's often the case that applications are multilayered

51
00:04:13,710 --> 00:04:19,350
and each layer has its own way of reporting and organizing errors this way.

52
00:04:19,380 --> 00:04:23,440
An exception thrown in the lower layer will be logged in each layer.

53
00:04:23,460 --> 00:04:24,250
It crosses.

54
00:04:24,510 --> 00:04:28,090
But finally, it will be handled in some of the upper layers.

55
00:04:28,680 --> 00:04:34,410
If the exception is thrown in the data access layer, it can be intercepted in the business layer,

56
00:04:34,560 --> 00:04:36,600
which logs it and then withdraws it.

57
00:04:37,260 --> 00:04:43,230
It is then handled in the interface layer by showing some pop up with an error message to the user.

58
00:04:43,830 --> 00:04:49,590
We'll talk more about how to resolve exceptions in the next lecture in a simplified way.

59
00:04:49,650 --> 00:04:51,870
Such cold could look like this.

60
00:04:52,930 --> 00:05:00,780
This is the lowest level player if an exception is thrown on data access, it's locked and ritual later,

61
00:05:00,790 --> 00:05:07,210
it will be handled by the next layer, the business layer if the data access layer throws an exception

62
00:05:07,210 --> 00:05:10,420
here, or if the processing of the raw data does.

63
00:05:10,660 --> 00:05:12,920
The exception will be logged and written.

64
00:05:13,330 --> 00:05:18,250
It will be truly handled by showing some error to the user in the uppermost layer.

65
00:05:18,520 --> 00:05:23,860
The graphical user interface layer this way, the exceptions are wrong.

66
00:05:23,860 --> 00:05:29,710
At the lowest layer of the application will be locked at each layer, but it will only be handled at

67
00:05:29,710 --> 00:05:33,770
the graphical user interface layer, as you can see at this point.

68
00:05:33,790 --> 00:05:38,020
It is not right or wrong, as this is the last place where it can be handled.

69
00:05:38,620 --> 00:05:44,880
Of course, if any of the lower layers could actually handle the exception and continue working without

70
00:05:44,890 --> 00:05:49,870
problem, it should not withdraw it and it would never be shown in the error window.

71
00:05:50,560 --> 00:05:57,970
Let's sum up using cut exception should be avoided because it captures every kind of exception when

72
00:05:57,970 --> 00:06:00,040
we decide to cut an exception.

73
00:06:00,190 --> 00:06:04,240
We should know how to handle it, and it's not feasible is the exception.

74
00:06:04,240 --> 00:06:05,380
Type is unknown.

75
00:06:05,920 --> 00:06:10,540
We should be precise in both cutting exceptions as well as in throwing them.

76
00:06:11,450 --> 00:06:18,200
During the interview, you could be asked what are the acceptable cases of cutting and a gap of exception?

77
00:06:18,830 --> 00:06:25,610
Well, the first one is the global cut block that catches on exceptions not handled elsewhere and brought

78
00:06:25,610 --> 00:06:26,840
them to the user.

79
00:06:27,320 --> 00:06:33,290
And the second is cut block in which we throw an exception without handling it.

80
00:06:33,740 --> 00:06:37,550
And the follow up question could be what is the global catch book?

81
00:06:38,210 --> 00:06:45,140
The global catch block is the catalog defined at the uppermost level of the application that is supposed

82
00:06:45,140 --> 00:06:48,380
to catch on the exceptions that haven't been handled elsewhere.

83
00:06:48,830 --> 00:06:55,910
It usually locks the exception and source some information to the user before stopping the application.

84
00:06:56,720 --> 00:06:57,350
All right.

85
00:06:57,530 --> 00:07:00,860
We'll continue the topic of exceptions in the next lecture.

86
00:07:01,220 --> 00:07:03,230
Thanks for watching, and I'll see you there.