1
public Card getCard()throws IOException{ Card c = null; String cardInfo = null; assert readStream != null: cardInfo = readStream.readLine(); assert cardInfo != null: c = CreateCard(cardInfo); return c; } 

I'm a little outta practice and I am trying to improve my code quality by using the assert statement to test for nulls. The way it seems to work I end up having to daisy chain my assertions because if the first thing I test for is null, then the next one is gonna be a null as well....

2
  • 2
    With Java assertions, the part after the colon is the message to the reader, and it goes to standard output. Also, if readStream is null, them the next part never gets executed, so you don't have to worry about cardInfo. But where are you getting readStream from? What is the purpose of this method? Commented Jun 20, 2013 at 4:34
  • Note that you need to launch the JVM with -ea for assertions to be enabled Commented Jun 20, 2013 at 4:35

2 Answers 2

1

Here are some guidelines with regards to assertions

  • Don't use assertions to validate parameters of public functions. These functions should throw NullPointerException, IllegalArgumentException, and other relevant exceptions instead. Since public functions will be used by other programmers, you should make sure that they get the right errors if they mess up.
  • Use assertions to check preconditions and postconditions on parameters of protected and private access methods.
  • Don't use assertions to check for software user errors. If you expect the user of your web-based online sales system to enter a 10-digit credit card number and she enters only 9 digits, don't use an assert. Instead, throw IllegalArgumentException. If you use assert, as soon as someone turns off assertions on your servlet container, the checking logic in your system would go away.
  • Use assertions to check parameters and variables for conditions that shouldn't happen
  • Use assertions to check for invalid code branches
  • Don't use an assertion to do any work. Assertions are developer-level errors and shouldn't be used to repair state in the program or perform complex logging. Also, don't forget that if a user runs the program without assertions, the code will be gone. If that code was critical to the functioning of the program, you could be in deep trouble.
  • Don't bother internationalizing assertion error messages. Again, since assertions are developer-level issues, internationalizing them would be a waste of time.
  • Use assertions to check post conditions. If you create a method and expect that it will never to return null to the user
Sign up to request clarification or add additional context in comments.

Comments

0

The value of an assertion is that it can be ON in development and OFF in production. While on, it reveals bugs, presumably before they do much damage, prior to a release. While off, the assertions are inactive and (hopefully) sport a negligible performance impact.

I think the question to ask yourself is: "Self, does my usage of assertions meet those criteria?"

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.