1

00:00:01,120  -->  00:00:04,310
Not just look at a few more citations from Effective Java.

2

00:00:04,710  -->  00:00:11,640
These are pretty simple steps and do not be doing any demonstrably scuzz them frontrunner's I don't

3

00:00:11,670  -->  00:00:17,800
57 NHS use exceptions only for exceptional conditions right.

4

00:00:17,830  -->  00:00:23,170
Grenada don't use them for controlling the flow of your program.

5

00:00:25,020  -->  00:00:29,630
An here's an example where an exception is used to control the flow of the program.

6

00:00:30,450  -->  00:00:35,600
Helots that you'll be a parceling a history document get hitched him and document it up as it did by

7

00:00:35,640  -->  00:00:37,470
some kind of it treaty.

8

00:00:37,520  -->  00:00:44,590
Dr. So we will be reading through the different notes of the Hatchie imagery hit the next night a third

9

00:00:44,740  -->  00:00:50,610
would read and the next element in the history of my document no after which I was the last and it meant

10

00:00:51,010  -->  00:00:52,860
then me and the next item added.

11

00:00:52,900  -->  00:00:54,240
It would throw an exception.

12

00:00:55,040  -->  00:00:56,800
So here you're are catching that exception.

13

00:00:57,020  -->  00:01:00,370
And we are done things that you're doing some complex logic.

14

00:01:00,470  -->  00:01:04,490
So the programs can go is dictated by the generation of exception.

15

00:01:04,730  -->  00:01:06,520
And this is something you should never do.

16

00:01:08,620  -->  00:01:10,300
You could instead do something like this.

17

00:01:10,630  -->  00:01:16,430
Well you would have a separate method that does great or not there are any more elements to recovers

18

00:01:17,350  -->  00:01:23,000
only if there is an element to hours then you would invoke the next item at that get this you don't

19

00:01:23,000  -->  00:01:30,040
have the exception so you need to write your logic in this way but not rely on exceptions for our growth

20

00:01:30,160  -->  00:01:30,490
.

21

00:01:32,360  -->  00:01:39,240
Nectars I don't for twenty nine inches avoid unnecessary use of checked exceptions know the technical

22

00:01:39,240  -->  00:01:44,710
options are great at making our programs reliable in the event of any exceptional conditions.

23

00:01:46,030  -->  00:01:53,140
But if you scurrilously then that would make the API far less pleasant to use as a force the API client

24

00:01:53,290  -->  00:01:55,500
to handle those exceptions.

25

00:01:55,510  -->  00:02:03,600
So this is an extra burden on the clients so use it or leave there can be an unpreventable exceptional

26

00:02:03,600  -->  00:02:08,260
condition under a client can actually recover from it.

27

00:02:09,240  -->  00:02:14,990
If one or both of these conditions do not hold then an exception would be more appropriate.

28

00:02:15,480  -->  00:02:23,470
So just be careful when you're thinking of using checked exceptions next is item 60 which is filled

29

00:02:23,510  -->  00:02:25,850
with the use of standard exceptions.

30

00:02:25,950  -->  00:02:32,020
And that's because the exceptions that come July we should be good enough most of the time.

31

00:02:32,120  -->  00:02:39,120
And so you don't have to introduce any new exception of process and here are some benefits of reusing

32

00:02:39,180  -->  00:02:46,470
existing exceptions the first one is a very important one using standard exceptions would make it easier

33

00:02:46,470  -->  00:02:52,760
to understand you would be a Consequently it would also make the program so if you are able at a glance

34

00:02:52,880  -->  00:03:00,510
easy to follow on here are a few commonly used exceptions and we're going to discuss them as there were

35

00:03:00,500  -->  00:03:02,660
already briefly discussed earlier.

36

00:03:04,440  -->  00:03:10,240
Next is item 60 do under this document all exceptions thrown by each method.

37

00:03:11,190  -->  00:03:18,530
According to this item it is very important to describe all the exceptions that a method can throw a

38

00:03:18,780  -->  00:03:21,090
using the method properly.

39

00:03:21,090  -->  00:03:29,300
Generally this addition is also often why later sometimes even public ice so when you're throwing exceptions

40

00:03:29,630  -->  00:03:38,260
exercise some patience big time to document all the exceptions that you and motard gross just recall

41

00:03:38,270  -->  00:03:47,140
that Tostig is used for documenting exceptions not ask for tidbits of Shin's declare each one individually

42

00:03:47,410  -->  00:03:54,800
and document them precisely indicating the conditions under which each one is strong buy individually

43

00:03:55,040  -->  00:03:59,860
it is meant to not take shortcuts like using one super polymorphic exception.

44

00:04:01,220  -->  00:04:09,900
That just don't do throws Exception or throws drawable doing this effectively obscure any specific exceptions

45

00:04:10,050  -->  00:04:11,810
that may be thrown by the matter.

46

00:04:12,240  -->  00:04:15,430
So use specific exceptions rather than generic ones.

47

00:04:17,250  -->  00:04:21,020
Know with regards to unchecked exceptions although it is optional.

48

00:04:21,040  -->  00:04:28,550
Declare them do document them as carefully as checked exceptions generally majority of untyped exceptions

49

00:04:28,760  -->  00:04:34,900
are thrown in the event or pre-conditioned by notions recall that a precondition violation is simply

50

00:04:34,900  -->  00:04:38,910
a failure by an A B or client to stick to the contract.

51

00:04:39,870  -->  00:04:46,530
If you recall even in our demo we used a precondition check in the Send method unhatched A.P. class

52

00:04:46,540  -->  00:04:47,400
.

53

00:04:47,490  -->  00:04:48,630
We also documented it.

54

00:04:48,690  -->  00:04:55,180
The other Rostok So this way users of them mattered were taken the necessary precautions when passing

55

00:04:55,180  -->  00:05:03,760
arguments one important thing the item says is that document unchecked exceptions but do not declare

56

00:05:03,760  -->  00:05:10,810
them in the matter declaration mission to disrupt any program or looking at your method to distinguish

57

00:05:11,020  -->  00:05:19,410
checked exceptions from unchecked once item also says that it is particularly important to document

58

00:05:19,520  -->  00:05:25,890
unchecked exceptions thrown by in defacement there is this where the documentation would be part of

59

00:05:26,430  -->  00:05:31,920
this contract and therefore in Ebers common behavior among its different implementations

60

00:05:34,290  -->  00:05:38,910
Finally there is also a related item from another chapter in effective Java.

61

00:05:38,940  -->  00:05:43,610
It is item 38 on says check barometers for validity.

62

00:05:43,680  -->  00:05:50,460
It's a precondition Jecks which we already discussed the item it raises us to think about barometer

63

00:05:50,460  -->  00:05:57,040
restrictions when writing new methods or constructor's and if there are any restrictions you need to

64

00:05:57,040  -->  00:06:02,920
check them at the beginning of the method and through any unchecked exceptions and also document them

65

00:06:03,010  -->  00:06:05,240
as we just discussed here.

66

00:06:05,290  -->  00:06:12,040
So that's for public markets but for nonpublic methods it is recommended to do parameter checks using

67

00:06:12,120  -->  00:06:18,770
an added feature of java called associates which we will see next so those are some more valuable divs

68

00:06:19,100  -->  00:06:21,130
and you should always keep them in your mind.

69

00:06:21,260  -->  00:06:21,680
Thank you