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 the advice in [jg:EXP02-J. Do not ignore values returned by methods ]. The returned value should be as representative of the last known state as possible and should be designed keeping in mind the perceptions and mental model of the Methods should always try to return a value that allows the developer to learn about the current state of the object and/or the result of an operation. This is consistent with the advice in EXP02-J. Do not ignore values returned by methods. The returned value should be as representative of the last known state as possible and should be designed keeping in mind the perceptions and mental model of the developer. Wiki Markup
Feedback can also be provided by throwing either standard or custom 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 provide a detailed account of the abnormal condition at the appropriate abstraction level.
To gain better ability at telling apart correct from fallacious results and enforcing that the incorrect results be carefully handled, a combination of the 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. Not Note that no possible failure codes should be within the range of valid return values.
...
Noncompliant code example
As shown in this noncompliant example, noncompliant methods that are susceptible to failure can silently corrupt the state of the object if they do not return a value that the developer can intuitively interpret.
Code Block | ||
---|---|---|
| ||
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 is to return This compliant solution recommends returning the result of the operation; true
for success and false
for failure.
Code Block | ||
---|---|---|
| ||
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 informative This compliant solution returns the updated Node
so that the developer can simply check for a null
value lest the operation fails. Appropriate return values for methods can vary depending on the control flow or the information that the developer finds more useful.
...
This solution combines the best of both worlds - exceptions and status codes. In this case, an exception is thrown if the operation is not successful. This ensures that the client has to handle the event wherein the Node
is not found. If the Node
is found, it is simply returned.
Code Block | ||
---|---|---|
| ||
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 NodeNotFoundException(); } |
...