Using exceptions to return exceptional values: is this good practice?
Question: Is it good Python practice to have a function return None most of the time,
while _exceptionally_ returning useful _values_ by _raising an exception where
the values are stored_?

I am a little uneasy with this because exceptions are most often used to
signal some kind of problem, with some attributes of the exception giving some
details about the problem. Here, I would like the exception to actually mean
"here is an exceptional _result_ of this function".

Using an exception for this is tempting because (1) this is only done in
exceptional circumstances and (2) this is efficient, in Python (more than an
`if … is not None:…`). On the other hand, the exception itself is not the sign
of an error of any sort, just a vehicle for the exceptionally returned values.

Is there any official recommendation against using exceptions for
exceptionally returning values from a function?

**PS** : Here is a use case:

  * An object method updates the internal state of the object based on new data (it's a finite state automaton).
  * At some point (usually after getting many data points), the method considers that some action must be taken (in my case: some date from the object should be stored in a database, and the object's state is reset to the initial state, where it is ready to get more data).

Thus, the sequence of events, for the method, is: get data, update state, get
data, update state,… ah! we reached an special state where information about
the object should be stored! reset the objet's state and send the relevant
information out; get data, update state, get data, update state,… Thus, most
of the time, the function updates the internal state of the object and does
not return anything. Exceptionally, it must send important information about
the object.


Answer: Exceptions can model _any_ exception to the normal flow of the code. Errors
are the most common use-case, but anything where the _normal_ return type
doesn't really make sense can be seen as an opportunity to raise an exception
instead.

Raising an exception for non-error use-cases is _perfectly fine_ , if it
simplifies your flow.

Remember, the `Exception` object raised and caught, is itself a value.
Attaching information to that is a perfectly acceptable method to communicate
with a caller to signal a deviation from 'normal'.

I'd prefer an exception over a sentinel value like `None`; it makes the
handling explicit, and can actually lead to cleaner handling and better
feedback to a developer when they forget to handle the exceptional return
value. If your code normally returns a list, but in specific, exceptional
circumstances, you return `None`, _and the caller doesn't handle it_ , then
you get weird bugs down the line somewhere. `TypeError: 'NoneType' object is
not iterable` is a lot more cryptic than an explicit unhandled exception.

