figure out API-error return pathway about magic-wormhole.rs HOT 2 CLOSED

Another option is to define some APIError event types for internal use, allow any machine's process() function to emit them, and have do_api() collect those just like it currently collects API Actions. But if it sees any error events, then do_api() returns an Err instead of an Ok. So do_api() -> Result<Actions, WormholeCoreError>, but none of the other machines' process() functions would return a Result. So the core would signal errors synchronously, which the API layer could then map into the approach of their choosing.

This would make it easier for e.g. Code::SetCode(code) to signal an error when the code is malformed. The main sticking point is to make sure that we haven't moved any other state machines in an irreversible way (although to be honest the Python code isn't very clear about how fatal errors are: if you make a mistake and submit a malformed code, then is the wormhole now permanently corrupted, or can you recover by trying again?).

from magic-wormhole.rs.

As of #94, all programmer related errors are eliminated at compile time by the type system. core sends any errors it has over the channel as APIEvent::GotError. The public API exposes this as a stream of Result<message type, error type>.

from magic-wormhole.rs.