OutstandingDesignIssues

This is a place for design issues that are currently outstanding but that I don't feel I have enough data yet to make the right decision.

Streaming decode error handling

There are several things that may interrupt a streaming decode:

1. The application has all the data it needs (either for this submessage or for the entiree message).
2. The application received invalid data and wants to abort the parse (for example, all required fields were not present).
3. The application encountered an error processing valid data (for example, a write to an output file returned in error).
4. The application can't process the data right now, but wants to resume later (for example, a write to an output file returned EAGAIN).

In response to an error, there are several things that should probably happen.

1. The error should be propagated to the caller, so it can tell the difference between eg. a parse error and an application error. But should outer submessages be able to modify the error that is ultimately reported, or even clear the error completely and make it look like a success?
2. Any resources that were acquired during processing should be cleaned up (like freeing any allocated memory). But should all resources be reachable at all times, so an explicit cleanup handler is unnecessary? Could we simply skip endmsg handlers in the case of error or exit?

Also, in the case that we want to stop parsing but not due to error, should endmsg handlers get called that could set the status to error?

There are too many possibilities here and not enough data to decide what applications will want. All that is really clear is that parsers should implement two primary operations: skip (to skip some portion of the input) and exit (exit the decoder, possibly in a resumable way). We can figure out exactly the chain of handlers that should be called in these cases later.