There are different approaches to the issue of not having a value to return.
</p>
<p>
A typical approach is to consider the existence of a valid return value as
a postcondition, so that if the function cannot compute the value to return,
it has either undefined behavior (and can use assert in a debug build) or
uses a runtime check and throws an exception if the postcondition is violated.
This is a reasonable choice for example, for function (A), because the lack
of a proper return value is directly related to an invalid parameter (out
of domain argument), so it is appropriate to require the callee to supply
only parameters in a valid domain for execution to continue normally.
</p>
<p>
However, function (B), because of its asynchronous nature, does not fail
just because it can't find a value to return; so it is incorrect to consider
such a situation an error and assert or throw an exception. This function
must return, and somehow, must tell the callee that it is not returning a
meaningful value.
</p>
<p>
A similar situation occurs with function (C): it is conceptually an error
to ask a <spanclass="emphasis"><em>null-area</em></span> polygon to return a point inside
itself, but in many applications, it is just impractical for performance
reasons to treat this as an error (because detecting that the polygon has
no area might be too expensive to be required to be tested previously), and
either an arbitrary point (typically at infinity) is returned, or some efficient
way to tell the callee that there is no such point is used.
</p>
<p>
There are various mechanisms to let functions communicate that the returned
value is not valid. One such mechanism, which is quite common since it has
zero or negligible overhead, is to use a special value which is reserved
to communicate this. Classical examples of such special values are <codeclass="computeroutput"><spanclass="identifier">EOF</span></code>, <codeclass="computeroutput"><spanclass="identifier">string</span><spanclass="special">::</span><spanclass="identifier">npos</span></code>,
points at infinity, etc...
</p>
<p>
When those values exist, i.e. the return type can hold all meaningful values
<spanclass="emphasis"><em>plus</em></span> the <spanclass="emphasis"><em>signal</em></span> value, this mechanism
is quite appropriate and well known. Unfortunately, there are cases when
such values do not exist. In these cases, the usual alternative is either
to use a wider type, such as <codeclass="computeroutput"><spanclass="keyword">int</span></code>
in place of <codeclass="computeroutput"><spanclass="keyword">char</span></code>; or a compound
type, such as <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">pair</span><spanclass="special"><</span><spanclass="identifier">point</span><spanclass="special">,</span><spanclass="keyword">bool</span><spanclass="special">></span></code>.
</p>
<p>
Returning a <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">pair</span><spanclass="special"><</span><spanclass="identifier">T</span><spanclass="special">,</span><spanclass="keyword">bool</span><spanclass="special">></span></code>, thus attaching a boolean flag to the
result which indicates if the result is meaningful, has the advantage that
can be turned into a consistent idiom since the first element of the pair
can be whatever the function would conceptually return. For example, the
last two functions could have the following interface:
<tdalign="right"><divclass="copyright-footer">Copyright © 2003-2007 Fernando Luis Cacciola Carballal<br>Copyright © 2014, 2015 Andrzej Krzemieński<p>