Which three statements are true? Assertion checking is typically enabled when a program is deployed. It is never appropriate to write code to handle failure of an assert statement. Assertion checking is typically enabled during program development and testing. Assertion checking can be selectively enabled or disabled on a per-package basis, but not on a per-class basis. Assertion checking can be selectively enabled or disabled on both a per-package basis and a per-class basis.

(1) is wrong. It's just not true.

(2) is correct. You're never supposed to handle an assertion failure.

(3) is correct. Assertions let you test your assumptions during development, but the assertion code—in effect—evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove.

(4) is wrong. See the explanation for (5) below.

(5) is correct. Assertion checking can be selectively enabled or disabled on a per-package basis. Note that the package default assertion status determines the assertion status for classes initialized in the future that belong to the named package or any of its "subpackages".

The assertion status can be set for a named top-level class and any nested classes contained therein. This setting takes precedence over the class loader's default assertion status, and over any applicable per-package default. If the named class is not a top-level class, the change of status will have no effect on the actual assertion status of any class.