Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: edited

Wiki Markup
According to \[[Ware 08|AA. Java References#Ware 08]\], methods should always return a value that allows the developer to know the current state of the object and/or the result of the operation. This is consistent with whatthe is statedadvice in [jg:EXP02-J. Do not ignore values returned by methods ]. The returned value should be as more representativerepresentative of the last known state as possible and should be designed considerkeeping thein waymind the perceptions developerand ismental goingmodel toof handlethe itdeveloper.

Feedback can also be provided by throwing exception objects derived from the Exception class. With this approach, the developer can still get precise information about the outcome of the method and proceed to take the necessary actions. To do so, the exception thrown should give provide a good description of the problem found in executiondetailed account of the abnormal condition at the appropriate abstraction level.

To achieve a better handling of both correct and incorrect resultsgain better ability at telling apart correct from fallacious results and enforcing that the incorrect results be carefully handled, a combination of the two previous approaches should be used. Be aware to differentiate between aforementioned approaches is recommended. At the same time, there are cases when an error value should be returned instead of an exception and vice versa. For instance, if some method is capable of failing in a variety of different ways, it is better to return failure codes than endeavoring to throw scores of different exceptions.

Noncompliant code example

As shown in this noncompliant example, methods that are subject to fail could compromise susceptible to failure can silently corrupt the state of the object if they do not return a value that the developer can interpret.

Code Block
bgColor#FFCCCC
public void updateNode(int id, int newValue){
		
  Node current = root;
  while(current != null){
    if(current.getId() == id){
      current.setValue(newValue);
      break;
    }
    current = current.next;
  }
}

Compliant solution

A recommended solution for this example could be is to return the result of the operation. The method could return true if it was successful and false if it wasn't; true for success and false for failure.

Code Block
bgColor#CCCCFF
public boolean updateNode(int id, int newValue){
		
  Node current = root;
  while(current != null){
    if(current.getId() == id){
      current.setValue(newValue);
      return true;
    }
    current = current.next;
  }
  return false;
}

Compliant solution

Another solution that could provide more information could return informative solution returns the updated Node so that the developer could verify the new state of the object and null if the operation did not succeedcan simply check for a null value lest the operation fails. Appropriate return values for methods could can vary depending on the different paths that the implementation can follow or on control flow or the information that the developer finds more useful.

Code Block
bgColor#CCCCFF
public Node updateNode(int id, int newValue){
	
  Node current = root;
  while(current != null){
    if(current.getId() == id){
      current.setValue(newValue);
      return current;
    }
    current = current.next;
  }
  return null;
}

Compliant solution

This solution provides a combination of both approaches mentionedcombines the best of both worlds - exceptions and status codes. In this case, an exception is thrown if the operation was is not successful. This ensures that the client has to handle the event wherein the Node is not found.

Code Block
bgColor#CCCCFF
public Node updateNode(int id, int newValue) throws IdNotFoundException {
  Node current = root;
  while(current != null){
    if(current.getId() == id){
      current.setValue(newValue);
      return current;
    }
    current = current.next;
  }
	
  throw new IdNotFoundExceptionNodeNotFoundException();
}

Risk assesment

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MET04-J

medium

unlikely probable

medium

P4 P8

L3 L2

References

Wiki Markup
\[[Ware 08|AA. Java References#Ware 08]\]