2 added 238 characters in body
source | link

Generally, I'd say that depends mainly on the following three aspects:

  1. robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package).

  2. code responsibility: if developer A is responsible for the getUser() method, and developer B uses it (e.g. as part of a library), I'd strongly recommend to validate its value. Just because developer B might not know about a change that results in a potential null return value.

  3. complexity: the higher the overall complexity of the program or environment is, the more I'd recommend to validate the return value. Even if you feel sure about that it cannot be null today in the context of the calling method, it might be that you have have to change getUser() for another use case. Once some months or years are gone, and some thousand lines of codes have been added, this can be quite a trap.

In addition, I'd recommend to document potential null return values in a JavaDoc comment. Due to highlighting of JavaDoc descriptions in the most IDEs, this can be a helpful warning for whoever uses getUser().

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

Generally, I'd say that depends mainly on the following three aspects:

  1. robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package).

  2. code responsibility: if developer A is responsible for the getUser() method, and developer B uses it (e.g. as part of a library), I'd strongly recommend to validate its value. Just because developer B might not know about a change that results in a potential null return value.

  3. complexity: the higher the overall complexity of the program or environment is, the more I'd recommend to validate the return value. Even if you feel sure about that it cannot be null today in the context of the calling method, it might be that you have have to change getUser() for another use case. Once some months or years are gone, and some thousand lines of codes have been added, this can be quite a trap.

In addition, I'd recommend to document potential null return values in a JavaDoc comment. Due to highlighting of JavaDoc descriptions in the most IDEs, this can be a helpful warning for whoever uses getUser().

Generally, I'd say that depends mainly on the following three aspects:

  1. robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package).

  2. code responsibility: if developer A is responsible for the getUser() method, and developer B uses it (e.g. as part of a library), I'd strongly recommend to validate its value. Just because developer B might not know about a change that results in a potential null return value.

  3. complexity: the higher the overall complexity of the program or environment is, the more I'd recommend to validate the return value. Even if you feel sure about that it cannot be null today in the context of the calling method, it might be that you have have to change getUser() for another use case. Once some months or years are gone, and some thousand lines of codes have been added, this can be quite a trap.

In addition, I'd recommend to document potential null return values in a JavaDoc comment. Due to highlighting of JavaDoc descriptions in the most IDEs, this can be a helpful warning for whoever uses getUser().

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}
1
source | link

Generally, I'd say that depends mainly on the following three aspects:

  1. robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package).

  2. code responsibility: if developer A is responsible for the getUser() method, and developer B uses it (e.g. as part of a library), I'd strongly recommend to validate its value. Just because developer B might not know about a change that results in a potential null return value.

  3. complexity: the higher the overall complexity of the program or environment is, the more I'd recommend to validate the return value. Even if you feel sure about that it cannot be null today in the context of the calling method, it might be that you have have to change getUser() for another use case. Once some months or years are gone, and some thousand lines of codes have been added, this can be quite a trap.

In addition, I'd recommend to document potential null return values in a JavaDoc comment. Due to highlighting of JavaDoc descriptions in the most IDEs, this can be a helpful warning for whoever uses getUser().