Message-ID: <719824938.5521.1422437576329.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5520_839895867.1422437576329" ------=_Part_5520_839895867.1422437576329 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Introduce Assertion= refactoring recommends that if a section of code is going to make an assum= ption about the current state of the program, that an explicit assertion sh= ould check those assumptions first.=20
A common usage of this refactoring is to check that each method (and pot= entially each constructor) checks its preconditions using assertions. This = is a particular form of defensive programming. Some argue that if you have = sufficient tests in place, you don't need to apply defensive programming. F= or the small extra performance penalty, it seems like a small price to pay = for extra resilience in our system.=20
Suppose we have the following method:=20 =20
If we call it with valid parameters, everything is fine. If we call it w=
ith null we will receive a
NullPointerException during the met=
hod's execution. This can sometimes be difficult to track down.
Applying this refactoring gives us the following code:=20 =20
This is better because we become aware of any problems straight away.