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 advice is consistent with the advice in guideline EXP00-J. Do not ignore values returned by methods. The returned value should be as representative as possible of the last known state as possible and should be chosen keeping in mind with the perceptions and mental model of the developer in mind.
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 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 in some cases when , an error value should be returned instead of an exception should be returned, 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 try to throw scores of different exceptions. Note that no possible failure codes should be within the range of valid return values.
| Wiki Markup |
|---|
Sometimes a state -testing method \[[Bloch 2008|AA. References#Bloch 08]\] can be used to ensure that the object is in consistent state at all points in time. This approach is not useful in the absence of external synchronization. There is also a time-of-check, time-of-use (TOCTOU) race condition between invocation of the object's state -testing method and the call to a method that depends on the object's state. During this interval, the object's state could change surreptitiously. |
...
This compliant solution returns the result of the operation; : true for success and false for failure.
...
This solution combines the best of both worlds - exceptions worldsâ”exceptions and status codes. In this case, an exception is thrown if the operation is not successfulunsuccessful. This The exception ensures that the client has to handle the event wherein the Node is not found. If the Node is found, it is updated and returned.
...
Failure to provide appropriate feedback through return values, error codes, and exceptions can lead to inconsistent object state and unexpected program behavior.
...
This guideline is similar to the C Secure Coding Standard recommendation ERR02-C. Avoid in-band error indicatorsThis guideline is similar and to the C++ Secure Coding Standard recommendation ERR02-CPP. Avoid in-band error indicators
...