Not let's look at assertions they are mainly about detecting errors during development and testing time 2
. 3
So let's see how they make that possible. 4
In this listen to what assertions are along with their benefits in the next lesson they will leave office 5
options. 6
There are two factors that contribute to software and reliability. 7
One is robustness while the other is correctness. 8
Robustness is the software's ability to withstand any errors that may happen in exceptional situations 9
. 10
That is the software should continue to execute in such exceptional situations and we have seen throughout 11
this chapter that this would be possible through exceptions and the corresponding exception handling 12
mechanism. 13
So what we have seen so far is all about robustness not Kirkman's as the name suggests deals with the 14
software working correctly. 15
And Sessions can help with correctness. 16
Normally when we develop software we write a record based on what we gather from our product managers 17
or any requirements documentation in the process. 18
We make certain assumptions and most of the time these are options would be right but sometimes them 19
emit wrongdo and it would be ideal could be kept them at development time itself. 20
So an exemption would be either right or wrong. 21
That is it is some kind of a boolean expression and we need to be able to test it. 22
And Sessions are helpful and testing out as options. 23
That is the correct method for programs and inserts statement has two forms. 24
And here is the first one. 25
In most keyword Essar followed by a boolean expression. 26
So this statement gets the boolean expression if boolean expression evaluates to true then everything 27
is good. 28
Uncontrolled most of the next statement. 29
Either way it implies that the program is not working correctly. 30
That is there is something wrong in our assumption in this case and it is such an error is thrown. 31
And the program is dominated immediately as there is no point continuing when the program is working 32
incorrectly. 33
As such an adder is a subclass of at a class and it is from the Dollard outline package. 34
Here we have a couple of examples. 35
First one is checking whether a reference variable named graph is null or not. 36
If it is not then an assertion error will be wrong. 37
Similarly a second example is checking whether the variable named index is greater than zero or normal 38
if it is less than or equal to zero. 39
And as such an order will be drawn. 40
Here is the second form of Kasota statement. 41
Here's the boolean expression is followed by a colon which is then followed by an error message. 42
In this case if boolean expression evaluates to false then an assertion at a restaurant but is initialized 43
with the error message. 44
We can also see an example here. 45
As for benefits assertions are very effective in quickly detecting bugs during development time and 46
as a statement implies an assumption that you think is right. 47
So if it fails for a particular instance of data then it means that you are as the it is wrong and you 48
have to fix it. 49
Moreover another might benefit as d also service documentation. 50
In some situations assertions can be better than comments. 51
For example let's assume that is a non-obvious competition and there is also a comment explaining it 52
. 53
But if some of the assumptions change and consequently the competition logic also changes then comments 54
will also have to change. 55
Otherwise comments would become out-of-date and hence will be out of sync with the code decisions on 56
the other hand are check that on time on so would most likely fail and will force their Blipper to update 57
them. 58
So in that sense assertions are like active comments. 59
Just the resources section where I included a few good pointers about benefits of assertions. 60
Assertions can be used anywhere in the program but one good place to use them is for validating method 61
parameters. 62
As this particular item recommends release because this item is the last lesson. 63
It's about validating metric parameters. 64
If parameters have any restrictions which are also referred to as preconditions. 65
So we perform some barometer checks for public methods. 66
The items are just throwing an unchecked exception if there is a violation of it. 67
Precondition. 68
We know that this would be a programming error from the API client but for non-public methods like the 69
private method the items are just using associates. 70
You shouldn't use assertions for public methods for reasons one reason his assertions are disabled by 71
default. 72
So there wouldn't be any barometer of validity checks and consequently any programming errors from Abiah 73
glance may go unnoticed. 74
Second reason is assertions to the universal assertion error which might not be that helpful for API 75
clients in fixing the problem. 76
But for non-public methods API clients are not in working them directly. 77
It is that in been the code that is invoking them. 78
So the owner of the board would be expected to test them extensively during development. 79
Get the help off as options. 80
This way in production non-public methods should always be invoked bit. 81
But I'm going to reduce. 82
No if you recall when the unit is also about correctness like assertions. 83
So the question would be Do we still need G-Unit or would only Jane itself wise. 84
Or can we have both G-Unit as well as options. 85
I would say as options would complement G-Unit what instance. 86
Let's assume you do not have G-Unit on how only assertions. 87
Now if you update some logic on your object and relevant assertions then how would you as the new logic 88
. 89
You mean tested with Vornado data instances. 90
I would just hope that it would work for other kinds of The Doctor. 91
But with you and it typically does the overcoaching Yes but different kinds of data in an automated 92
way. 93
We know that unit testing is all about automated repeatable dusting off. 94
Program correctness. 95
That is not if the program changes should break our desk Issus. 96
So you definitely do need G-Unit also. 97
G-Unit is generally about functioning of the entire metrics and not just about method parameters or 98
a single statement within a method. 99
So generally speaking G-Unit is about a block of code but with assertions most of the time you're dealing 100
at a more granular level like a single statement or one on one method parameters but the granular level 101
of testing is also important in validating our exemptions so we need both of them for program correctness 102
. 103
But J testing is definitely a required thing especially if you want to sleep peacefully. 104
Also just note that g unit also had some kind of met that. 105
Also true. 106
An assertion error in case of any issues so G-Unit is making use of a standard exception as recommended 107
by one of the effective dhal items which were discussed earlier. 108
Finally assertions are disabled by default to ensure that they are not performance liability on production 109
systems to enable them. 110
The command line option hyphenate can be passed with a job lined up later as transfer enabled as options 111
. 112
Alternatively hyphen an able assertions can also be used. 113
Assertions can be enabled disabled at specific class and package levels too put the sibling heifer India 114
or hyphen miscible exceptions can be used. 115
Here's an example. 116
Their assertions are unable that a class level here that enabled. 117
Only for the class hello and for all other classes that are disabled which as we said is their default 118
behavior. 119
As you can see we have the year flag followed by a colon which is in turn followed by a fully qualified 120
class name and that's how you enable it for a single class. 121
This example shows disabling off assertions at a class level so the previous one was an Eberling across 122
level. 123
Well this one is about disabling. 124
Your assertions are unable dupatta you like but they are disabled only for that class Hello. 125
What it means is assertions are enabled for the class Miklas on any class as it may be accessing with 126
the exception of Hello class. 127
No this example shows discipling of assertions at package level here. 128
Assertions or anybody from my class and he grasps it. 129
Maybe accessing except for all classes in the package. 130
Com dot semantics career 3.0 suggest a package. 131
So basically if you're dealing with specific class or package then you or be flag will be followed by 132
a colon which isn't followed by class or package name. 133
Just having an able flag by itself will enable assertions in Gendron having just disable flag by itself 134
has no effect as as options are disabled by default. 135
Ideally assertions should help in fixing all issues during development time and should be turned off 136
during production. 137
So that's what assertions and we will look at them off as options. 138
Thank you